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ABSTBACT 


The  Naval  Facilities  Engineering  Command  utilizes 
several  automated  systems  in  carrying  out  its  mission.  These 
systems  are  presently  geared  toward  the  Headquarters  and 
major  Command  levels  cf  management  and  not  toward  the  field 
activities  and  smaller  offices.  This  thesis  examines  an 
Architect-Engineer  type  contracting  management  procedure  and 
proposes  an  automated  alternative  of  the  contract  adminis- 
tration process  using  micro-computer  technology  for  field 
activities.  A  brief  examination  is  made  of  the  NAVFAC  auto- 
mated systems  and  of  the  structure  of  the  NAVFAC  contracting 
organization  prior  to  the  presentation  of  a  proposed  A-E 
Management  Information  System.  The  closing  chapters  discuss 
integration  of  the  proposed  system,  automated  tools  which 
make  the  system  possible  and  the  interface  designs  utilize! 
to  make  the  system  user  friendly. 


"BRAKY 


TABLE    OF    CONTENTS 


I.  INTRODUCTION 10 

A.  OVERVIEW 10 

B.  GOALS  AND  OBJECTIVES 12 

II.  NAVAL  FACILITIES  ENGINEERING  COMMAND  14 

A.  NAVFAC  CONTRACTING  14 

B.  NAVFAC  CONTRACTING  ORGANIZATION   15 

1.  Engineering  Field  Divisions   16 

2.  Naval  Shore  Activities  18 

3.  Officer  In  Charge  of  Construction   ....  18 

4.  Resident  Officer  In  Charge  of 
Construction  18 

III.  BACKGROUND 20 

A.  NAVAL  FACIIITIES  SYSTEM   .  ; 20 

1.  System  Overview 20 

2.  Data  Ease  Management  System 22 

3.  Distributing  The  System 26 

4.  Automated  Information  Systems   27 

B.  FACILITIES  SYSTEMS  OFFICE   31 

C.  LIMITATIONS  OF  THE  NAVAL  FACILITIES  SYSTEM  .  .  33 

IV.  A-E  CONTRACTING  PROCESS 35 

A.  GENERAL 35 

B.  PRE-NEGOTIATION  PHASE  (I)   36 

C.  NEGOTIATION  PHASE  (II) 39 

D.  FOST-AWARL  PHASE  (III) 42 

V.  REQUIREMENTS  DETERMINATION  48 

A.   WHY  AN  AUTOMATED  SYSTEM? 48 


B.  THE  COMPUTER-BASED  ENVIRONMENT  51 

1.  Simple  Data  Processing  System   51 

2.  Integrated  File-Oriented  Data 

Processing  System   52 

3.  Management  Information  System   53 

4.  Information  Resource  Management  System  .  .  54 

C.  ROICC  A-E  CONTRACTING  MIS 55 

D.  PROPOSED  J-E  CONTRACTING  SYSTEM   56 

VI.  AUTOMATION  OF  THE  PRE-NEGOTIATION  PHASE   58 

A.  REQUEST  FOR  CONTRACT  (1.1) 58 

B.  CONTRACT  SPECIALIST  ASSIGNED  (1.2)  59 

C.  DEVELOPMENT  OF  STATEMENT  OF  WORK  (1.3)  ....  60 

D.  DETAILED  GOVERNMENT  ESTIMATE  (1.4)  61 

E-   REQUIRED  CIEARANCES  AND  APPROVALS  (1.5)   ...  61 

F.  SMALL  BUSINESS  SET  ASIDE  RECOMMENDATION 

(1.6)   62 

G.  COMMERCE  BUSINESS  DAILY  SYNOPSIS  (1.7)  ....  62 

H.   LOGGING  OF  SF  254  AND  SF  255  (1.8) 62 

I.   BOARD  APPOINTMENT  LETTERS  (1.9)   63 

J.   PRE-SELECTION  (1.10) 63 

VII.  AUTOMATION  OF  THE  NEGOTIATION  PHASE   65 

A.  INTERVIEW  LETTERS  (II.  1) 65 

B.  INTERVIEW  OF  THE  A-E  FIRMS  (II.  2) 65 

C.  SELECTION  CF  A  CONTRACTOR  (II. 3) 66 

D.  REQUEST  FOR  FEE  PROPOSAL  (II.  4)   66 

E.  RECEIPT  OF  THE  FEE  PROPOSAL  (II. 5) 67 

F.  PRE-NEGOTIATION  (II. 6) 67 

G.  NEGOTIATION  BOARD  MEETING  (II. 7)  68 

H.   NEGOTIATION  BOARD  REPORT  APPROVAL  (II. 8)  ...  68 

I.   CONTRACT  AWARD  (II.  9)   68 

VIII.  AUTOMATION  OF  THE  POST-AWARD  PROCESS  69 

A.   NOTIFICATION  LETTERS  (III.1)  69 


B.  INDIVIDOAI  PROCUREMENT  ACTION  (DD  FORM 

350)   (III. 2) 70 

C.  OTHER  REPORTS  (III.  3)   71 

D.  DISTRIBUTION  OF  CONTRACT  (III. 4)  71 

E.  CONTRACTOR  MEETINGS  (III. 5)   71 

F.  DESIGN  REVIEWS  (III. 6) 72 

G.  CONTRACT  MODIFICATIONS  (III. 7)  72 

H.  PROGRESS  PAYMENTS  (III. 8)   73 

I.  DISPUTES,  ERRORS,  OMISSIONS,  DESIGN 

DEFICIENCES,  A-E  LIABILITY  (III. 9)  74 

J.  FINAL  PAYMENT  (III.  10) 74 

K.  CONTRACTOR  RELEASE  (III.  11)   74 

L.  A-E  PERFORMANCE  REPORT  DD  1413  (III . 1 2)   ...  75 

IX.  END-USER  INTERFACE  76 

A.   END-USER  PERCEPTIONS  76 

E.   SCREEN  DESIGNS 77 

1.  Menus 78 

2.  Prompts 79 

3.  Information  Presentation  80 

4.  Data  Presentation 81 

5.  Text  Presentation 82 

6.  Messages  and  Replies 83 

7.  Help  Facilities 85 

C.   INTERFACE  TRADE-OFFS  85 

X.  SYSTEM  INTEGRATION  87 

A.  OVERVIEW 87 

B.  DATA  DICTIONARY 89 

C.  IMPLEMENTATION  OF  THE  MIS 89 

XI.  CONCLUSIONS  AND  RECOMMENDATIONS   92 

A.  CONCLUSIONS 92 

B.  RECOMMENDATIONS 93 


APPENDIX  A:   SAMPLE  SfPLICATION  96 

APPENEIX  B:   A-E  MANAGEMENT  INFORMATION  SYSTEM 

COMPONENTS 122 

LIST  CI  REFERENCES 124 

INITIAL  DISTRIBUTION  IIST  125 


LIST  OF  FIGURES 

2.1  NAVFAC  Contract  Organization  16 

3.1  Navy  Facilities  System 21 

3.2  EFD/MIS  DDP  Configuration 28 

2.3  NFS  Distributed  Network 32 

1.1  Pre-Negotiation  Phase  Flowchart   38 

4.2  Negotiation  Phase  Flowchart   40 

4.3  Post-Award  Phase  Flowchart  43 

5.1  Simple  Data  Processing 52 

5.2  Integrated  File-Oriented  Processing   54 

5.3  Management  Information  System   55 

9.1  Contractor  Information  System  Main  Menu   ....  78 

9.2  Data  Entry  Screen  for  CIS 80 

9.3  CIS  Contractor  Discipline  Profile  Screen  ....  82 

9.4  .  Text  Presentation  in  the  CIS  Module 83 

9.5  CIS  Sign-on  Screen  Display  84 

9.6  Sample  Error  Message  85 

10.1  A-E  Contracting  MIS 88 


I-  IOJQ DOC TION 

A.   CvIBVIEW 

The  Naval  Facilities  Engineering  Command  has  the  mission 
within  the  Navy  of  the  plant  management  of  naval  shore 
facilities.  The  support  structure  for  the  organization  is 
comprised  of  upper  level  program  managers,  geographically 
located  design  divisions,  intermediate  contracting  offices 
and  activity  level  monitoring  staffs.  One  major  management 
function  of  NAVFAC  contracting  is  for  Architect-Engineering 
services,  maintenance  services  and  construction.  This  func- 
tion, as  well  as  the  other  NAVFAC  functions,  is  supported 
through  an  automated  management  system  which  has  grown  from 
a  mechanized  accounting  system  in  the  late  1940's  to  a 
quasi-distributed  automated  system.  To  a  limited  extent,  the 
functional  distribution  of  the  system  has  reached  some 
Engineering  Field  Divisions  and  is  beginning  to  reach  scire 
field  activities.  This  thesis  will  explore  the  possitlity 
of  automating  the  field  activity  functions  concerned  with 
the  Architect-Engineering  contract  process. 

The  following  is  an  overview  of  the  thesis  chapters: 
Chapter  II.   -  Naval  Facilities  Engineering  Command 

The  overall  mission  of  the   command  and  in  particular 
the  contracting  aspect  are  discussed. 
Chapter  III.   -  Naval  Facilities  System  (NFS) 

The  automated  management  system  is  discussed.  The 
major  components  which  constitute  the  NAVFAC  informa- 
tion system  are  described  along  with  a  discussion  of 
the  advantages  and  benefits  of  evolving  from  a  file 
oriented  structure  to  a  generalized  Data  Base 
Management   Sjstem.     The  Naval   Facilities   Systems 
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Office  is  described  and  its  changing  role  in  the  NFS 
is  discussed. 

Chapter  IV.   -  The  A-E  Contracting  Process 

A  brief  description  os  given  of  the  steps  required  by 
the  contract  administration  staff  to  put  an  A-E 
contract  through  the  three  phases  of  the  A-E 
contracting  life-cycle,  pre-negotiation,  negotiation, 
and  post-award  phases. 

££§££.§£  !•      ~   Requirements  Determination 

The  automated  support  needed  by  the  field  activities 
to  adequately  use  the  data  collected  for  the  NFS  is 
identified.  Tcols  are  described  which  could  be  used 
to  build  a  proposed  management  information  system  for 
the  A-E  contracting  environment. 

Chapter  VI.  -  Automation  of  the  Pre-Negotiation  Phase 
Discussion  of  a  proposed  management  information 
system  for  the  A-E  contract  administration  process 
begins  in  this  chapter  and  concludes  in  chapter  8. 
The  Pre-Negotiation  steps  are  discussed  in  the  auto- 
mated environment.  Means  and  methods  of  automating 
the  process  are  investigated.  The  major  concepts 
involved  are  the  use  of  databases,  report/letter 
files  and  application  modules  to  drive  the  entire 
contracting  administration  process. 

£k§£l§£  VII.   -  Automation  of  the  Negotiation  Phase 
A  similar  approach  is  taken  as  described  in 
Chapter  6. 

Chapter  VIII .   -  Automation  of  the  Post-Award  Phase 
A  similar  approach  is  taken  as  described  in 
Chapter  6. 

Chapter  IX.   -  End-Oser  Interface 

Considerations  of  the  users  of  the  automated  systems 
in  terms  of  the  best  interface  design  are  discuss€d. 
Also   discussed  are   the   factors   that   affect   the 
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end-user's  perception  of  the  system  and  various 
screen  design  methodologies.  Samples  of  recommended 
screen  designs  are  presented. 

Chapter  X.   -  System  Integration 

An  overall  view  of  the  proposed  automated  A-E 
contracting  system  is  presented  along  with  a  review 
of  the  automated  tools  which  comprise  the  subsystems 
of  the  MIS  for  the  A-E  process.  The  chapter  concludes 
with  a  discussion  of  how  the  field  office  could  best 
utilize  an  automated  system  to  meet  NFS  requirements 
as  well  as  satisfy  local  management  needs. 

Chapter  XI.   -  Conclusions  and  Recommendations 

General  conclusions  and  recommendations  for 
inplementation  of  the  system  in  the  field  are 
discussed. 


B.   GCAIS  AMD  OBJECTIVES 

The  objectives  of  this  thesis  are  threefold.  The  author 
focuses  en  the  manageaent  process  of  the  NAVFAC  Contracting 
Organization  and  how  this  process  affects  the  field  Public 
Works  Officer,  the  Officer  In  Charge  of  Construction,  and 
the  Resident  Officer  In  Charge  of  Construction.  This  will 
satisf j  the  objective  of  the  author  to  become  acquainted 
with  the  Navy  Facilities  System  Plan  £Ref.  1  ].  Second,  a 
sample  mcdule  of  a  proposed  automated  tracking  and  reporting 
management  system  for  A-E  contracting  is  presented  through 
the  application  of  a  database  management  system.  This 
permits  the  investigation  of  the  possible  uses  of  a  micro- 
computer database  management  system  in  a  field,  non- 
programming,  professional  environment.  The  third  objective 
is  to  investigate  the  possibility  of  developing  a 
user-friendly  interface   between  a   complex   micro-computer 
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database  system  and  the  novice  user.  If  such  a  interface  is 
possirle,  the  application  of  micro-computer  based  database 
management  systems  can  be  expanded. 
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II.  NAVAL  FACILITIES  ENGINEERING  COMMAND 

A.   NAVJAC  CONTRACTING 

The  Naval  Facilities  Engineering  Command  (NAVFACENGCCM) 
is  responsible  for  and  authorized  to  perform  the  design, 
planning,  development,  procurement,  construction,  altera- 
tion, repair  and  maintenance  at  all  shore  activities  cf  the 
Naval  Fstahlishment  for  public  works  and  public  utilities 
[Ref.  2:  p. 1.3.1].  This  responsibility  is  assigned  by  the 
Secretary  of  the  Navy  through  the  Chief  of  Naval  Materiel. 

The  specific   functions  performed  under  this   authority 
are  as  fellows: 

a.  Approving  the  selection  and  compensation  of  an 
architect  or  engineer; 

b.  Approving  the  selection  and  fee  of  a  general  fcuilding 
contractor; 

c.  Consent  to  the  placement  of  any  subcontract  fcr  civil 
works; 

d.  Approving  any  plans  or  specifications; 

e.  Approving  of  major  alterations  or  increased  costs 
within  the  estimated  cost  set  forth  in  a  contract  for 
civil  works; 

f.  Inspection,  supervision,  and  administration  cf  the 
terms  of  subcontract  and  acceptance  of  performance; 

g.  Monitoring  compliance  with  labor  standards 
requirements; 

h.  Ordering   or   approving   changes   relating   tc   civil 

works; 
i.  Cognizance  of  all  matters  relating  to  the  acquisition 

of  real  property.   [Ref.  3] 
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In  essence,  NAVFAC  is  responsible  for  any  construction 
related  activities  from  cradle  to  grave  throughout  the  Naval 
Shore  Establishment.  This  thesis  will  primarily  focus  on 
the  first  function  mentioned  above,  Architect-Engineering 
contracts.  These  contracting  services  are  utilized  by  the 
NAVFAC  organization  to  augment  in-house  planning  and  design 
capability.  Architect-Engineering  contracts  (hereafter 
referred  to  as  A-E  contracts)  are  used  primarily  tc  procure 
design  drawings  and  specifications  for  contemplated 
construction  or  maintenance  and  repair  projects.  A-E 
contracts  can  also  be  utilized  as  a  means:  1)  to  providing 
consultation  to  contract  administrators  during  construction 
projects;  2)  to  incorporate  specialized  review  and  checking 
of  accuracy  of  contractor's  drawing,  material  lists,  or 
equipment  performance  data;  3)  to  prepare  record  drawings  or 
update  master  drawings  and  plans;  and  4)  to  acquire  inspec- 
tion services  for  construction  work  in  instances  where 
in-house  expertise  is  non-existent  or  not  available. 

B."   NAVFAC  CONTBACTIHG  ORGANIZATION 

The  sole  "Contracting  Officer"  within  NAVFAC  is  the 
Commander,  NAVFACENGCCM.  All  ether  persons  exercising  NAVFAC 
contracting  authority  act  and  sign  in  the  stead  of  the 
Commander.  The  NAVFAC  Contract  Organization  is  shown  below 
in  Figure  2.1. 

The  primary  players  in  the  contracting  chain  are  the 
Commander  NAVFAC,  Engineering  Field  Divisions  (ZFD) , 
Of f icers-In-Charge- cf-Constr uction  (OICC) ,  and  the  Resident 
Of f icers-In-Char ge-cf-Construction.  As  can  be  seen  in 
Figure  2.1,  the  Comnander  NAVFAC  sits  at  the  head  of  the 
organization  where  all  final  contracting  decisions  reside. 
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Figure  2.1    NAVFAC  Contract  Organization, 


1 .   Engineering  Fie Id  Divisions 

The  EFDs  are  organizationally  patterned  after 
Headquarters,  NAVFAC.  A  major  department  of  the  EFD  is  the 
Acquisition  Department.  Four  divisions  under  the  supervision 
of  the  Acquisition  Department  Director  concern  themselves 
with  the  acguisiticr  process:  1)  Acguisition  Project 
Management  Division;  2)  Contract  Division;  3)  Design 
Division;  and  the  4)  Construction  Division. 

a.   Acguisiticn  Division 

The  Acguisition  Project  Management  Division 
performs  many  general  acquisition  management  functions.  Its 
major  mission  is  to  monitor  and  coordinate  the  execution  of 
construction  contracts.  In  this  role/  the  EFD  serves  activ- 
ities which  are  located  in  a  NAVFAC  designated  geographical 
area.  responsibility.  To  meet  this  program  management  func- 
tion,   the    EFD   develops   listings   of    prospective   A-S 
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contractors,  makes  selections  of  contractors  for  specific 
design  contracts  and  negotiates  contract  fees.  Once 
contracts  are  awarded,  the  staff  coordinates  and  reviews 
contract  design  and  construction  matters.  Any  proposed 
changes  in  the  scope  of  contracts  are  reviewed  ty  this 
office. 

h.   Contract  Division 

The  Contract  Division  is  concerned  with  the 
legal  contractual  matters  and  the  contract  administration 
process.  This  division  provides  the  field  OICC  and  EOICC 
with  interpretations  of  contracts,  policy  guidance  and 
recommendations  on  claims.  Basically,  the  Contract  Division 
acts  as  a  consultant  to  field  contracting  offices  on  more 
difficult  contractual  matters. 

c.  Design  Division 

The  Design  Division  is  a  "government- owned 
Architect  and  Engineering  organization"  so  to  speak.  It 
performs  the  same  design  functions  that  most  commercial  A-E 
firms  provide.  Approximately  25%  of  the  Design  Division's 
effort  is  strict  engineering  design  with  the  remaining  75% 
directed  toward  engineering  contracts  management  and 
consulting.  The  Design  Division  reviews  A-E  contracted 
designs  to  ensure  maximum  utilization  of  design  criteria  for 
economical  design  cost  and  quality  construction.  For  field 
activities  they  review  all  field  designs  and  provide 
technical  consultation  on  design  matters. 

d.  Construction     Contract     Management     and 
Administration  Division 

The  Construction  Contract  Management  and 
Administration  Division  manages  construction  execution  to 
achieve  timely,  quality  construction.  This  division  receives 
support  from  the  three  other  divisions  mentioned  above. 
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2  .   Nai^l  Shore  Activities 

Each  Naval  Shcre  Activity  Commanding  Officer  has  en 
his  staff  a  Civil  Engineer  Corps  officer  who  is  responsible 
for  the  facility  management  of  the  station.  This  officer 
will  re  either  the  Public  Works  Officer  (PWO)  or  a  Staff 
Civil  Engineer  (SCE)  who  in  turn  will  interface  with  the 
station  EWO.  This  officer  and  possibly  his  staff  will 
ensure  the  NAVFAC  mission  is  carried  oat  as  described  ahove. 
The  EED,  OICC,  and  EOICC  support  the  PWO/SCE.  The  PW0/SC2 
navigates  projects  through  these  offices  requesting  the 
services  required  tc  properly  manage  the  maintenance, 
repair,  alteration  and  construction  of  local  Naval  Shcre 
assets. 

3  •   Cf f icer  In  Charge  of  Construction 

The  OICC  receives  designs  and  contract  specifica- 
tions from  the  EFDs  and  the  PWO  to  be  awarded  as  construc- 
tion contracts.  The  OICC  maintains  lists  of  prospective 
contractors  as  well  as  issues  Request  for  Proposals  and 
Invitations  for  Bids.  Contractors  are  screened  by  the  C1CC 
staff  to  determine  if  they  qualify  to  bid  on  Navy  construc- 
tion contracts.  This  OICC  office  awards  the  construction 
contracts,  issues  change  orders  to  existing  contracts  and 
approves  performance  payments.  The  official  contract  files 
are  maintained  by  the  OICC. 

4 .   Resident  Officer  In  Ch  ar_ge  of  Construction 

The  ROICC  administers  the  construction  contracts 
awarded  ty  the  OICC  cften  physically  located  at  the  EED.  The 
ROICC  is  also  functionally  responsible  to  the  local  Naval 
Shore  activity  to  ensure  the  contractor  provides  the  best 
guality  construction  permitted  under  the  contract.  The  ROICC 
works  directly  with  the  contractor  in  the  daily  execution  of 
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the  contracts.  This  interface  includes  inspections  of  work; 
review  cf  material  sukmittals;  approval  of  payment  requests, 
schedules,  estimates,  shop  drawings,  etc;  and  the  review  and 
surveillance  of  the  contractor's  Quality  Control  system. 

These  four  organizations,  from  EFDs  down  to  the 
KOICC,  constitute  the  contracting  family  of  NAVFAC.  The 
focus  in  this  thesis  is  on  those  elements  of  the  EOICC  and 
Naval  Shore  Activities  which  are  concerned  with  contracted 
A-E  design  efforts.  These  are  the  organizations  who  would 
benefit  the  most  from  the  micro-computer  based  management 
system  proposed  herein. 
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III.  BACKGROUND 

A.   NAVAI  FACILITIES  SYSTEM 
1 .   System  Overview 

NAVFAC  has  a  single  Automated  Data  Processing  System 
called  the  Naval  Facilities  System  (NFS) .  The  automated  data 
processirg  plan  for  the  command  is  published  annually  in  the 
NAVFAC  F-424,  the  Naval  Facilities  System  Plan  [Ref.  1]. 
This  plan  provides  the  short  and  long  range  ADP  corporate 
planning  for  NAVFAC.  The  intent  of  the  plan  is  to  optimize 
the  information  technology  currently  available  and  integrate 
existing  management  systems  to  permit  the  managers  of 
programs  to  more  effectively  meet  their  missions.  The  plan 
is  coordinated  with  and  developed  in  conjunction  with  the 
Command  Management  Plan,  the  NAVFAC  command  budget  and  the 
Navy  ADP  budget. 

The  NFS  is  an  accumulation  of  15  interfacing 
Automated  Information  Systems  (AISs) .  These  systems  are 
utilized  in  determining  the  requirements,  making  the  acqui- 
sitions and  monitoring  the  utilization  of  real  property, 
utilities,  and  all  forms  of  civil  engineering  support. 
Figure  3.1  shows  the  relationship  between  the  Requirements, 
Acquisition,  and  Utilization  of  Real  Property,  Utilities, 
and  Civil  Engineering  Support.  Naval  Force  Planning  deter- 
mines base  loading,  some  required  human  resources  and  the 
mobilization  plans.  The  mobilization  plans  generate  a 
requirement  for  Civil  Engineer  Support  which  further  places 
a  need  for  human  resources  which  in  turn  further  increases 
base  loading.  The  requirements  for  real  property  and 
utilities  are  determined  once  these  needs  are  identified. 
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Acquisition  of  real  property,  utility  systems  and  equipment 
are  budgeted  for  and  then  carried  out.  The  combined  utiliza- 
tion of  the  real  property,  utilities  and  equipment  produce 
the  desired  capability  espoused  by  the  Naval  Force  Planning. 
Pour  AISs  are  of  importance  to  this  thesis.  These  AISs  are 
Management  Information  Systems  (MIS)  for  use  by  NAVFAC 
Headquarters,  the  Engineering  Field  Divisions  (EFD) ,  the 
Construction  Battalicn  Centers  (CBC) ,  and  the  Public  Works 
Centers  (PWC)  .  The  other  11  AISs  are  functional  as 
Navy-wide  applications  in  environmental  protection;  in  shore 
facilities  planning  and  real  estate;  in  military  construc- 
tion programming;  in  support  of  the  Naval  Construction 
Force;  in  construction,  automotive,  and  special  equipment; 
in  base  engineering  support,  energy  conservation,  engi- 
neering research,  family  housing,  base  operating  support; 
and  in  occupational  safety  and  health/deficiency  abatement. 

2  •   Eat  a  Base  Man  a_geroen  t  System 

The  accumulation  and  management  of  the  data  required 
to  support  the  15  AISs  presents  a  management  challenge. 
Since  the  mid-70 fs  the  thrust  in  supporting  these  AISs  has 
been  to  adapt  a  generalized  Data  Base  Management  System 
(DBMS)  approach.  Conversion  to  a  DBMS  from  a  conventional 
file  oriented  systems  is  a  time  consuming  process.  This 
approach  continues  today  to  replace  the  existing  file 
oriented  system  of  the  NFS  where  a  particular  application 
has  to  have  it's  own  data  file.  A  database  management  system 
is  a  software  tool  that  is  designed  to  manage  and  maintain 
an  organization's  database  resource.  The  DBMS  itself  is  not 
tied  to  any  particular  set  of  files,   [fief.  4:  p. 333] 

a.   Benefits  of  the  DBMS 

The  conversion  to   a  DBMS   has   many  long   term 
benefits.   Data  captured  in  the  database  becomes  application 
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independent.  The  data  structure  of  the  data  in  the  database 
remains  the  same  no  matter  what  the  application,  causing 
some  standardization  of  application  development  since  all 
applications  must  access  the  same  structured  data.  However, 
this  does  not  limit  the  applications  since  applications  can 
build  different  views  of  the  data  simply  by  accessing  and 
merging  the  data  to  suit  the  application  needs.  For  example, 
one  program  could  be  written  to  track  contracts  in  separate 
geographic  areas.  The  program  could  produce  reports  tased 
on  just  cne  region  or  it  could  combine  or  extract  data  from 
the  datatase  to  produce  a  NAVFAC-wide  report. 

Existing  software  is  able  to  provide  logical  as 
well  as  physical  data  independence,  enhancing  the  data 
storage  economies.  Eedundant  data  need  not  be  stored  for 
several  applications.  The  evolution  of  the  datatase  can 
proceed  without  the  spiralling  cost  of  maintenance  for 
application  programs.  There  no  longer  needs  to  be  updates  to 
application  programs  due  to  data  changes.  With  DBMS  comes 
utility  programs  to  assist  the  Data  Base  Administrators 
(DBA)  to  act  as  controllers  and  custodians  of  the  data  to 
ensure  integrity  of  the  data  and  enforce  the  proper  struc- 
ture. (The  centralized  datatase  system  currently  in  use 
will  te  discussed  later  in  this  chapter.)  Along  with  integ- 
rity comes  the  requirement  to  protect  the  data  through 
proper  security  measures.  The  data  for  the  most  part  is 
unclassified  administrative  data  for  military  purposes,  yet 
it  is  in  a  sense  administratively  confidential  and  must 
therefore  be  protected.  Access  to  the  database  must  be 
limited  to  those  who  have  a  need  to  know.  The  DBMS  utilities 
will  accommodate  this  requirement  also.  Since  the  DBMS  is 
generalized,  data  migration  across  devices  can  be  facili- 
tated much  easier  as  the  proliferation  of  hardware 
increases.  In  governmental  systems  this  is  important  consid- 
ering  the   limitation   of   the   ADP   procurement   policies. 
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Managers  of  systems  can  not  always  predict  the  brand  of 
hardware  a  particular  procurement  action  will  produce. 
Another  consideration  is  that  of  an  evolving  functional 
distribution  system.  As  the  system  grows  horizontally  or 
vertically,  the  new  nodes  that  are  placed  on  the  systen;  may 
or  may  not  be  compatible  with  existing  system  hardware. 
Existing  equipment  must  be  either  directly  compatible  or 
must  be  able  to  interface  through  various  protocols. 

A  current  goal  of  the  NFS  is  the  development  of 
a  complete  data  dictionary  to  cover  all  the  AIS.  This  is 
imperative  for  the  proper  control  of  the  data  validity.  The 
data  dictionary  standardizes  the  data  formats  and  the  actual 
meaning  cf  the  data  elements  for  all  command  systems.  This 
is  not  new  to  the  AIS  but  simply  a  feature  to  have  a  fully 
functioning  DBMS.  The  DBMS  also  permits  various  levels  of 
access  to  the  database.  The  DBA  is  be  able  to  define  the 
structure  of  the  database  through  the  use  of  the  data  defi- 
nition language  (DDL) .  The  DDL  includes  terms  for  defining 
records,  fields,  keys,  and  relationships.  It  also  provides 
facilities  for  expressing  a  variety  of  user  views  and  allows 
the  imposition  of  user  constraints  such  as  editing  capa- 
bility, interrecord  and  intrarecord  browsing.  Access  to  the 
database  by  application  programmers  is  through  the  use  of 
the  database  command  language.  Applications  can  te  written 
for  novice  users  of  the  system  at  EFDs  and  field  activities 
such  that  the  details  of  accessing  the  database  are 
completely  transparent.  For  more  sophisticated  users  who 
wish  to  access  the  database  directly,  a  query  language  is 
available.  This  permits  queries  to  be  made  of  the  database 
to  obtain  quick  answers  to  unanticipated  or  one-time 
guer ies. 
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h.   Advantages  of  a  DBMS 

A  generalized  DBMS  has  many  advantages  over  a 
conventional  file  oriented  structure.  The  DBMS  allows  more 
information  to  he  pulled  from  the  same  data.  Consider  a 
distributed  system  where  field  ROICC  offices  would  he  atle 
to  access  a  large  database.  Several  applications  could  be 
made  from  the  same  scurce  data.  For  example,  contract  admin- 
istration on  a  series  of  contracts  could  be  used  to  track 
the  current  workload  at  the  HOICC  level.  The  same  data  at 
the  EID  level  could  he  used  to  review  the  distribution  of 
design  efforts  over  the  EFD's  geographical  area  of  responsi- 
bility. At  the  NAVFAC  level  the  same  data  could  be  used  by  a 
program  manager  in  the  development  of  budget  estimations  for 
the  upcoming  budget  piocess.  The  partitioning  of  data  in  a 
conventional  file  system  makes  the  process  of  gathering  data 
for  these  different  applications  difficult.  In  the  conven- 
tional system,  to  avoid  this  difficulty  it  becomes  necessary 
to  maintain  a  file  for  each  application  creating  vast 
amounts  of  data  redundancy.  Thus  the  DBMS  saves  memory 
space,  speeds  processing  and  data  entry,  as  well  as  enhances 
the  data  integrity. 

c.   Disadvantages  of  a  DBMS 

With  any  improved  system  there  also  exist  seme 
disadvantages  and  turning  to  a  generalized  DBMS  from  a 
conventional  file  oriented  system  is  no  exception.  DBMSs  are 
expensive  to  procure  and  implement  requiring  longer  term 
benefits  to  justify  the  initial  cost.  A  generalized  DBMS  can 
require  a  new  series  of  processors.  This  is  important  if 
the  corporate  processing  involves  more  than  just  database 
processing.  A  dedicated  processor  is  often  the  best  invest- 
ment since  it  will  permit  parallel  processing  of  database 
accesses  and   applications.    Highly   trained  personnel   are 
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required  to  maintain  the  DBMS  environment  and  administration 
and  ccntrol  of  the  DBMS  is  more  complex  than  the  file 
oriented  systems.  Administrative  and  operating  cost  can  be 
expected  to  increase-  Considering  the  disadvantages  and 
comparing  them  to  tie  overall  advantages,  the  long  term 
lenefits  of  the  DBMS  over  the  conventional  file  oriented 
system  can  easily  justify  any  of  the  mentioned 
disadvantages. 

3  •   Distributing  The  System 

Another  NFS  initiative  which  reflects  the  changing 
philosophy  of  NAVFAC  is  that  of  expanding  the  number  of 
users  of  the  NFS.  This  expansion  is  being  accomplished 
through  decentralization  and  distribution  of  the  NFS. 
Project  smart  (source  management  of  resources  and  time)  is 
leing  inrlemented  for  use  at  the  EFD/OICC  level.  The  project 
consists  of  installing  minicomputers  at  the  EFDs  and  CICCs 
to  permit  the  i nplementation  of  local  management  tcols  and 
the  standardization  of  existing  office  automation  systems. 
The  objectives  of  project  smart  are: 

a)  provide   additional   processing  capability   for   the 

EFD/OICC; 

b)  achieve   system   revision   and   integration   through 

evolution  net  revolution; 

c)  provide  a   user  friendly   interface  to   permit  query 

language  access  to  the  generalized  DBMS; 

d)  develop  local  application's  from   the  initial  instal- 

lation. 
Project  smart   is  scheduled  to   be  fully  implemented   in  all 
EFDs  and  NAVFAC  HQ  by  the  end  of  FY87.   [Ref.  1:  p. 5-10] 

Another  form   of  distributing  the   NFS  has   teen  the 
decision  to  provide  "teleprocessing"   to  the  EFDs.   Hardware 
has  been  connected  frcm  the  Facilities  System  Office  (FACSO) 
in  Port  Hueneme,   Ca.   to  the   EFDs  and  to  NAVFAC  HQ  through 
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the  use  cf  telecommur.ication  lines.  The  hardware  includes 
terminals  for  input/output  operations,  and  hardcopy 
printers.  The  remote  sites  can  input  data  directly  tc  the 
nain  ccmputer  at  FACSC  as  well  as  receive  management  reports 
at  local  printers.  This  type  of  distributed  processing  has 
proven  tc  be  more  effective  and  efficient  than  the  totally 
centralized  approach  used  previously.  [Ref.  1:  p. 5-1].  The 
benefits  include  reduced  input  time,  a  more  accurate  data 
discipline,  and  improved  delivery  time  for  outputs. 
Reporting  reguirements  have  also  declined  due  to  the  ability 
of  the  user  to  make  cr-line  gueries  of  the  database. 

**  •   Automated  Infer  ma  tio  n  Sys te ms 

Of  the  15  AISs,  only  the  EFD/MIS  will  be  focused 
upon  in  the  remainder  of  the  thesis.  The  EFD/MIS  serves  the 
management  reguirements  of  the  EFDs,  large  OICCs  and  NAVrAC 
HQ.  This  distributed  data  processing  (DDP)  conf iguraticn  is 
shown  in  figure  3.2  below.  The  major  data  systems  cf  the 
MIS  are: 

(1)  The   "AMALGAKAN"   Data   Base    which   supports   the 
following: 

(a)  Integrated  Disbursing  and  Accounting  (IDA) 

(b)  Integrated  Program  Management  System  (IPMS) 

(c)  Construction  Management  System  (CMS) 

(2)  Design  Management  Information  System  (DMIS) 

(3)  Graphics  Design  System  (GDS) 

(4)  Contractor  Information  System  (CIS) 

The  EFD/MIS  has  over  200  computer  programs  and  produces 
approximately  200  standard  titled  reports.  [Ref.  5:  p.i] 
The  data  systems  which  are  of  primary  interest  to  the  EOICC 
are  the  CMS,  DMIS  and  the  CIS. 
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a.  Construction  Management  System  (CMS) 

The  objective  of  the  CMS  is  to  provide  the 
NAVFAC  level  program  managers  with  the  information  required 
to  monitor  and  control  the  design  and  construction  phases  of 
shore  facilities  projects.  The  reports  produced  provide 
Project  Status  (used  ty  EFD/OICC  and  HQ) ,  Execution  Status 
(used  by  EFD  and  HQ)  ,  Work  In  Place  (used  by  ROICC, 
EFD/OICC,  and  HQ)  and  various  other  management  reports. 
[Ref.  5:  p. 31] 

b.  Design  Management  Information  System  (DKIS) 

The  DMIS  is  utilized  by  HQ  and  EFD/OICC  design 
managers  tc  manage  the  engineering  and  design  phases  of  the 
NAVFAC  mission.  Three  functional  areas  are  directly 
supported:  design  scheduling,  criteria  scheduling,  and  engi- 
neering and  design  management. 

C)   Design  Scheduling. 

Design   scheduling   involves   design   job 
status,   design   scheduling,   personnel   resource  allocation 
(in-house   vs.   contract) ,    job  cost  control,   and   design 
perfcraance  appraisal. 

(2)  Criteria  Scheduling. 

This  application  involves  the  design 
schedule,  milestones,  and  funding  information  used  in  sched- 
uling and  coordinating  the  preparation  of  design  criteria. 
The  system  is  used  tc  plan  goals  that  will  be  established  in 
the  Command  Management  Plan  (NAVFAC  P-441),  and  to  document 
the  progress  of  the  design  goals  which  have  already  been 
estatlished. 

(3)  Engineering  and  Design  Management. 

Used  by  EFD/CICC  and  HQ  program  managers, 
this  application  combines  data  from  several  data  files  and 
aggregates  it  to  a  high  level  to  monitor  the  progress  of 
projects  at  the  EFD/CICC  and  HQ  levels. 
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c.  Contractor  Information  System  (CIS) 

The  CIS  is  designed:  1)  to  standardize  proce- 
dures for  maintaining  contractor  information  for  the  A-E 
slates  and  mailing  lists;  2)  maintaining  history  of  the 
contractors  efforts  for  the  U.S.  Navy;  and  3) providing 
contractor  data  to  the  CMS  and  IDA  systems  [Ref.  6:  P-1]» 
The  CIS  is  utilized  by  all  levels  of  NAVFAC  management  for 
all  varieties  of  contractor  information.  The  information  for 
the  CIS  is  drawn  from  contractor  submitted  questionnaires 
(A-E  and  Related  Services  SF  254)  and  Bidder's  Mailing  List 
Application  (SF  129) .  Updates  are  made  periodically  as  more 
information  is  accumulated  on  various  contractors  through 
submittal  of  follow-cr  SF  254s. 

d.  NFS  Goals  for  the  EFD/MIS 

The  NFSP,  [Ref.  1:  pp. 1-12  -  1-21]  outlines 
several  short  and  long  term  goals  for  the  EFD/MIS  which  in 
general  lead  toward  a  distributed  data  processing  system 
where  the  end-user  will  be  able  to  work  directly  from  the 
generalized  database  system  in  a  virtual  mode.  Some  specific 
goals  are: 

*  Implement    automated    procedures    for    reporting 

individual  procurement  actions  (DD  350  reports). 

*  Develop   a    word    processing/central    processing 

interface  for  the  ROICC. 

*  Convert   AMALGAMAN/CMS   to  DBMS   with  on-line   guery 

capabilities. 

*  Implement  Graphics   Design  System  at   the  EFD   and  HQ 

levels. 

*  Convert    the   DMIS    to   D3MS   for   on-line    guery 

capabilities. 
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B.   FACIIITIES  SYSTEHS  OFFICE 

The  Facilities  Systems  Office  (FACSO)  is  the  hut  cf  the 
NAVFAC  data  processing  system.  Located  at  the  Construction 
Eattalicn  Center,  Pert  Hueneme,  Ca.,  FACSO  is  responsible 
for  the  majority  of  the  development  and  operation  01  the 
NFS.  FACSO's  distributed  network  is  shown  in  figure  3.3 
below. 

FACSC  has  an  IBB  370/165-11  computer  system  with  4 
million  characters  of  main  memory,  22  gigabytes  of  on-line 
storage,  26  tape  drives,  2  high-speed  non-impact  printers, 
and  6  high-speed  impact  printers.  Two  coupled  Interactive 
Data  Ease  Processors  (IDBPs)  with  4  million  bytes  of  memory 
each  were  installed  in  1981/82.  The  IDBPs  handle  all  data- 
base applications  and  share  most  of  the  peripheral  equip- 
ment, thus  relieving  the  370/165-11  of  considerable 
workload.  A  COMTEN  3690  Front  End  Processor  handles  the 
majority  of  the  telecommunications  interface.  The  device  is 
programmable  and  switchable  so  that  a  given  port  can  handle 
different  types  of  input  terminals  and  route  messages  under 
program  control.  Communication  ports  are  assigned 
dynamically  to  accommodate  the  fluctuating  load.  [Ref.  1: 
p. 4-1] 
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C.   IIHITATIONS  OF  THE  NAVAL  FACILITIES  SYSTEM 

The  paragraphs  above  have  briefly  explained  the  NFS  and 
in  particular  the  EFD/MIS.  The  life  of  the  NFS  continues  to 
he  a  dynamic  one  as  are  all  long  term  data  processing 
systems.  The  system  has  shown  all  the  signs  of  growth  as 
described  by  Nolan  [ Eef .  7  :  pp. 115-126].  The  system  began 
as  a  central  data  processing  point  where  all  input  was 
either  sent  via  the  postal  services  or  transmitted  electron- 
ically via  message.  The  data  was  required  to  be  key  punched 
on  data  cards  and  submitted  in  a  batch  mode  with  output 
reports  sent  to  the  users  via  the  postal  service.  The  time 
lapse  from  the  time  the  field  activities  submitted  their 
data  to  FACSO  (via  the  EFD)  to  the  time  the  output  reports 
were  received  could  be  as  long  as  five  months  but  was 
normally  in  the  order  of  at  least  three  months.  This  manage- 
ment system  did  not  meet  the  management  needs  of  the  field 
activities.  Today  however,  the  NFS  provides  the  EFDs  and 
NAVFAC  HQ  tetter  management  support  due  to  the  advances  in 
telecommunications  and  the  availability  of  distributed 
processing  at  the  EFD  level. 

A  large  majority  of  the  data  for  the  EFD/MIS  coir.es  from 
the  field  ROICC  offices.  These  offices  accumulate  this  data 
over  a  period  of  a  month,  in  most  cases  manually,  and  submit 
it  to  the  EFD  where  it  is  validated  and  transmitted  directly 
to  FACSC  through  use  of  the  EFD/MIS  DDP  system  (Figure 
3. 2). The  ROICC  office  will  normally  receive  a  management 
report  within  six  weeks.  This  data  is  in  the  most  part 
historical  and  can  net  be  used  to  effectively  manage  a  day 
to  day  operation.  Trerefore  the  collection  and  reporting  of 
the  data  is  only  an  overhead  expense  to  the  field  activity. 

Plans  for  the  future  for  the  NFS  call  for  the  field 
activities  to  have  a  virtual  connection  to  FACSO  just  as  the 
EFDs  enjoy  now.    This  will  permit  the  ROICC  to  collect  data 
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electronically  and  in  turn  transmit  probably  via  the  ZFD 
processors  to  FACSO.  The  ROICC  will  also  be  able  to  keep 
on-hand  the  data  for  management  of  daily  operations.  These 
advances  are  just  beginning  to  be  seen  for  some  BOICC 
offices.  TCANG  Office  Information  System  (OIS)  hardware/ 
software  is  used  to  permit  collection  of  required  data.  The 
data  is  presently  transmitted  to  the  EFD  by  mailing  disks. 
Direct  transmission  to  the  EFDs  is  not  possible  at  the 
present  time.  A  main  concern  of  this  thesis  is  investi- 
gating a  method  by  which  the  field  activities  can  locally 
utilize  the  data  which  is  collected  for  higher  level  manage- 
ment. Currently,  the  majority  of  the  data  remains  to  be 
historical  in  nature.  Systems  can  be  developed  which  will 
incorporate  the  collected  data  into  the  daily  management 
functions  of  the  field  activity.  The  remainder  of  the  chap- 
ters will  be  devoted  to  the  development  of  such  a  system  for 
the  management  of  the  A-E  contracting  process. 
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IV.  1-E  CONTRACTING  PROCESS 

A,   GENEEA1 

As  mentioned  earlier,  A-E  contracts  are  used  prinarily 
to  procure  the  drawings  and  specifications  for  contemplated 
construction  projects  [Bef.  2:  p. 2.1.1].  These  contracts 
are  awarded  throughout  the  NAVFAC  contracting  chain.  While 
all  the  contracts  are  awarded  by  following  the  same  required 
contractual  procedures  [Ref.  2],  the  actual  process  will 
differ  from  command  to  command  due  to  differing  maragement 
styles  of  individual  managers  and  the  local  "traditional 
policies".  The  process  described  below  is  generic  in  the 
•sense  that  all  the  A-E  contracts  go  through  the  same  three 
phases  no  matter  which  command  is  concerned.  There  are  many 
rules  and  regulations  which  govern  the  process  but  it  is  net 
the  intent  of  this  chapter  to  fully  discuss  all  the  legal 
requirements  of  contracting  but  rather  to  focus  primarily  on 
the  process  and  the  accompanying  information  flow  that  the 
manager  must  be  aware  of  in  order  to  manage  the  process. 

Within  the  A-E  type  of  procurement  there  are  several 
different  types  of  contracts.  The  main  difference  in  the 
various  types  is  the  number  of  "actions"  or  "products"  which 
can  be  delivered  under  one  contract.  Some  contracts, 
normally  larger  in  award  amount,  require  the  design  of  one 
construction  project.  Other  contracts  are  "open-end"  in  that 
a  larger  number  of  designs,  normally  small  in  nature,  can  be 
accomplished  under  one  contracting  vehicle.  Open- end 
contracts  often  are  not  to  exceed  a  predetermined  total 
amount.  These  contracts  are  negotiated  based  on  hourly  fees 
for  particular  technical  skills  rather  than  for  a  total 
design  cost  basis.    Follow-on  work  is  negotiated    based  on 


35 


the  hours  required  to  accomplish  a  design  task  which  is  then 
translated  into  an  award  fee. 

The  A-E  contracting  process  is  broken  into  three  phases, 
the  pre-negotiation  phase,  the  negotiation  phase  and  the 
post-award  phase.  Each  transition  from  one  phase  tc  another 
is  marked  by  a  distinct  result  or  action.  The  pre- 
negotiation  phase  involves  the  initial  request  for  a 
contract  submitted  by  a  customer.  The  phase  ends  when  a 
slate  of  a  few  contractors  is  approved  by  the  selection 
official  for  further  consideration.  The  negotiation  phase 
begins  with  the  selection  of  the  best  qualified  contractor 
from  the  slate  and  concludes  with  the  awarding  of  a  negoti- 
ated contract.  Post-award  is  the  actual  contract  execution 
phase.  It  begins  immediately  upon  the  signing  of  a  contract 
and  finishes  when  all  contracted  work  has  been  accepted  by 
the  government  and  final  payment  to  the  contractor  has  beer- 
made. 

There  are  several  parties  involved  in  the  contracting 
process.  These  include  the  contracting  officer  (OICC, 
ROICC,  AEOICC) ,  the  customer  (organization  whom  the  design 
is  to  benefit) ,  the  contract  administration  staff,  govern- 
ment engineers  (review  the  contractor's  work  and  accept  it 
as  being  correct),  and  lastly  the  contracted  A-E  firm.  The 
parties  are  involved  to  differing  levels  throughout  the 
contracting  process  as  will  be  seen  in  the  following 
paragraphs. 

B.   PBE-NEGOTIATION  PHASE  (I) 

The  steps  in  the  Pre-Negotiation  Phase  (I)  are  carried 
out  primarily  by  the  contract  administration  staff.  Other 
key  participants  in  this  phase  are  various  board  members  as 
well  as  the  customer.  The  customer  may  be  someone  in  the 
immediate  contracting   organization   itself   or   mayfce  an 
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organization  which   is  supported  by  the   contracting  office. 
Figure  4.1  is  a  flowchart  depicting  the  steps  listed  below. 

1.1  Request  for  contract  -  The  contracting  officer  receives 
a  request  for  an  A-E  contract.  A  determination  has 
already  been  made  that  the  design  cannot  be  handled  by 
the  in-house  engineering  staff. 

1.2  Contract  Specialist  (CS)  assigned  -  The  contracting 
officer  assigns  a  CS  to  handle  the  contract  request. 
This  CS  may  administer  the  contract  from  the  beginning 
of  the  contract  to  the  end  or  the  CS  may  simply  handle 
the  contract  until  the  award  is  made,  depending  en  the 
local  policy. 

1.3  Development  of  Statement  of  Work  (SOW)  -  The  requesting 
customer  or  the  in-house  engineering  staff  will  develop 
the  SOW  for  the  contract.  The  CS  reviews  the  SOW  for 
completeness  and  correctness.  The  developer  of  the  SOW 
draws  up  the  weighted  criteria  by  which  the  best 
gualified  contractor  can  be  selected. 

1.4  Detailed  Government  Estimate  (GE)  -  In  most  cases  the 
writer  of  the  SOW  also  draws  up  the  GE. 

1.5  Required  Clearances  and  Approvals  -  Depending  on  the 
type  of  funds  used  for  the  design  and  the  type  of 
design,  certain  clearances  and/or  approvals  may  be 
necessary  from  higher  command  levels  before  further 
action  can  be  taken  in  the  contract  process. 

1.6  Small  Business  Set  Aside  Recommendation  -  A 
determination  must  be  made  as  to  whether  the  contract 
will  be  open  to  large  business  or  remain  as  a  small 
business  set  aside. 

1.7  Commerce  Business  Daily  Synopsis  (CBD)  -  The  CS  will 
prepare  the  synopsis  for  the  CBD  and  ensure  that  it  is 
mailed.  The  CBD  announcement  is  a  notice  of  intent  to 
contract. 
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Figure   4.1        Pre-Negotiation   Phase   Flowchart. 
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1.8  Logging  of  SF  254s  and  255s  -  Contractors  responding  to 
the  contracting  announcement  in  the  CBD  are  required  to 
submit  their  firm's  qualification  on  the  SF  254  (general 
contractor  information)  and  the  SF  255  (contractor 
information  directed  toward  a  particular  announced 
contract  action) . 

1.9  Board  Appointment  Letters  -  The  A-E  contracting  process 
requires'  three  contract  boards:  pre-selection  board, 
selection  board,  and  the  negotiation  and  award  beard. 
Appointment  letters  assigning  the  members  of  the  hoard 
must  be  sent  out. 

1.10  Pre-selection  -  The  pre-selection  process  is  carried 
out  by  the  pre-selection  board.  All  contractors  submit- 
ting a  SF  255  for  the  contract  are  considered.  The  SF 
255s  are  reviewed  by  the  board  members  and  the  field  of 
gualified  contractors  is  narrowed  to  a  manageable 
number.  The  board  members  are  guided  in  their  selection 
of  the  qualified  contractors  by  the  selection  criteria 
developed  by  the  customer  or  engineering  staff.  The 
slate  of  qualified  contractors  is  approved  by  the 
approving  authority  (based  on  the  amount  of  the 
contract) .  The  approval  of  the  pre-selection  board 
report  by  the  proper  authority  is  the  concluding  action 
of  the  pre-negotiation  phase. 

C.   HEGOTIATION  PHASE  (II) 

The  Negotiation  Phase  carries  the  process  through  the 
actual  award  of  the  contract.  The  customer  plays  a  minimal 
role  in  this  phase  with  the  key  players  being  the  pre- 
selected contractors,  the  selection  and  contract  award 
board,  the  selected  contractor  and  the  CS.  Figure  4.2 
depicts  the  negotiation  steps  listed  below. 
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Figure  4.2   Hegotiation  Phase  Flowchart. 
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11. 1  Interview  Letters  -  Those  contractors  approved  on  the 
Pre- Selection  Board  report  are  sent  letters  to  inform 
them  of  their  pre-selection  and  to  establish  a  time  and 
place  for  an  in-depth  interview  before  the  Selection 
Board. 

11. 2  Interview  of  the  A-E  firms  -  Individual  interviews  are 
conducted  for  each  A-E  contractor.  The  Board  members 
evaluate  the  contractors  against  the  criteria  published 
in  the  CBD  announcement. 

11. 3  Selection  of  a  contractor  -  Based  on  the  interviews, 
the  Selection  board  members  select  a  contractor  who  best 
satisfies  the  selection  criteria.  A  Board  report  is 
prepared  and  signed  by  all  members  of  the  Board.  The 
proper  approving  authority  (depending  on  the  amount  of 
the  contract)  will  either  approve  or  disapprove  the 
selection  of  the  Eoard. 

II. U  Bequest  for  Fee  Proposal  -  A  request  for  a  fee  proposal 
is  sent  to  the  selected  contractor.  Depending  on  the 
size  of  the  contract,  various  documents  may  also  be 
required  of  the  contractor. 

11. 5  Receipt  of  the  Fee  Proposal  -  The  fee  proposal  when 
received  is  forward  to  a  lead  engineer  for  review.  The 
engineer  may  or  may  not  be  the  customer.  In  a 
multi-disciplined  contract,  the  proposal  may  be  sent  to 
several  engineers.  The  engineers  may  be  on  the  Selection 
and  Award  Board  as  well.  Here  again,  depending  on  the 
size  of  the  contract,  various  clearances  may  be 
required. 

11. 6  Pre-nego tiation  -  The  lead  engineers  in  conjunction 
with  the  CS  will  perform  the  pre-negotiations  with  the 
contractor.  This  can  result  in  revisions  of  both  the 
government  estimate  and  the  contractor  estimate  as  well 
as  clarifications  of  the  SOW.  All  actions  which  take 
place  are  recorded  by  the  CS. 
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11. 7  Negotiation  Board  meeting  -  Once  negotiations  with  the 
contractor  are  settled,  the  Negotiation  Board  is  called 
to  meet  in  order  to  review  the  negotiation  proceedings. 
If  the  proceedings  are  agreeable  to  all  the  board 
members,  the  board  report  is  prepared  and  signed  by  all 
the  members  and  is  then  forwarded  to  the  proper  approval 
authority  for  approval. 

11. 8  Negotiation  Beard  Beport  Approval  -  The  approving 
authority  reviews  the  Negotiation  Board  report  and 
approves  or  disapproves. 

11. 9  Contract  Award  -  Once  the  approving  authority  approves 
the  Negotiation  Ecard  report  the  contract  can  be  signed 
by  the  proper  authority.  The  signed  contract  is  then 
sent  to  the  contractor  for  signature. 

D.   PCST-ASARD  PHASE  (III) 

The  Post-Award  Phase  carries  the  contract  process 
through  management  and  administration  to  the  final  payment 
and  closing  of  the  contract.  The  normal  players  in  this 
phase  are  the  contractor,  the  lead  engineer  who  will  review 
the  contractor's  drawings/  and  the  CS  who  must  process  the 
payments  for  the  contract.  The  contracting  officer  may  get 
involved  if  problems  arise  in  the  contract.  Figure  4.3 
illustrates  the  steps  of  this  third  phase.  The  contract 
modification  steps  are  not  shown  here  since  the  same  steps 
are  followed  as  in  the  negotiation  phase. 

111. 1  Notification  Letters  -  Letters  are  sent  to  all  the 
non-selected  contractors.  These  letters  inform  the 
contractors  of  the  contract  award. 

111. 2  Individual  Procurement  Action  (DD  Form  350)  -  Contract 
actions  exceeding  $10,000  require  the  filing  of  a  DD 
Form  350.  This  form  is  normally  submitted  to  the  EFD. 
The  form  contains  information   pertaining  to  the  awarded 
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Figure   4.3        Post- Award  Phase   Flowchart. 
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contract   and  the  procedures  utilized   in  awarding   the 
contract. 

111. 3  Other  Reports  -  Depending  on  the  size  of  the  contract, 
it  may  be  necessary  to  notify  NAVFAC  of  the  award  and 
also  submit  an  award  announcement  to  the  CED. 

111. 4  Distribution  of  Contract  -  Once  all  the  signatures  are 
obtained,  the  contract  can  be  reproduced.  The  contractor 
will  be  sent  several  copies  as  will  the  EFD  "and  the 
customer. 

111. 5  Contractor  Meetings  -  Pricr  to  the  actual  beginning  of 
the  design  effort,  it  may  be  necessary  to  meet  with  the 
contractor  to  discuss  administrative  matters  or  design 
specifics.  Similar  meetings  may  occur  throughout  the 
life  of  the  contract. 

111. 6  Design  Reviews  -  Design  reviews  are  for  the  purpose  of 
reviewing  the  contractors  work  to  ensure  the  government 
is  obtaining  the  design  as  requested.  It  also  is  a  key 
feedhack  mechanism  to  ensure  customer  satisfaction. 
Design  reviews  occur  normally  when  the  designs  are  at 
the  30%,  60%,  90S  and  final  or  100%  complete  points.  If 
the  design  is  time  critical,  the  60^  review  will 
normally  be  waived.  The  lead  engineer  will  coordinate 
the  reviews  with  the  customers.  The  customers  are  often 
non-technical  and  the  lead  engineer  serves  as  the 
"interpreter".  The  lead  engineer  communicates  to  the  CS 
whether  or  not  the  submittals  meet  the  specifications  of 
the  contract.  The  relationship  between  the  CS  and  the 
lead  engineer  is  of  upmost  importance  in  the  post-award 
phase. 

111. 7  Contract  Modifications  -  Contract  modification 
procedures  are  very  similar  to  the  procedures  in  the 
pre-award  phase.  The  procedures  are  as  follows: 

1)  Request   for  contract   modification  -  This   would 
normally   be   in   the   form   of   a   request   for 
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additional  work  or  for  a  time  extension  for 
existing  work.  The  customer  will  generate  the 
request  for  additional  work  and  the  contractor 
would  request  the  time  extension. 

2)  Changes  Board  appointment  letters  -  Letters   are 

sent  to  Change  Order  Board  members  notifying  them 
of  the  time,  place  and  circumstances  of  the 
change. 

3)  SOW  revision  -   The  SOW  is  amended   to  reflect  the 

change. 

4)  Preparation  of  the  GE  -  The  GE  is  developed  by  the 

lead  engineer. 
5}  Bequest   for  Fee   Proposal  -   The   revised  SOW  is 
forwarded  to   the  contractor   with  a   request  for 
the  firm  to  provide  a  fee  proposal. 

6)  Beceipt  of  Fee   Proposal  -   The  contractor's   Fee 

Proposal  is  received  by  the  CS  and  forwarded  to 
the  lead  engineer  for  review  and  validation. 

7)  Pre-Negotiation  contact  with  the   contractor  -  The 

contractor  is  contacted  by  the  lead  engineer  and 
the  CS  to  discuss  differences  in  the  contractor's 
estimate  and  the  GE .  If  required,  any 
clarifications  are  made  and  a  preliminary 
agreement  is  established.  The  GE  or  the 
contractor's  estimate  may  be  adjusted  as 
appropriate. 

B)  Preparation  of  the  proposal  analysis  for  the 
negotiation  board  -  The  CS  will  prepare  an 
analysis  for  review  by  the  change  order 
negotiation  board.  The  analysis  will  cover  all 
the  preliminary  discussion  between  the  contractor 
and  the  CS/lead  engineer  team. 

9)  Change  order  negotiation  board  meeting  -  The  board 
meets  to   discuss  the  CS's  prepared   analysis  and 
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to  determine  if  the  contractor's  proposal  is  fair 
and  reasonable. 

10)  Board  retort  preparation  -  The  CS  prepares  a 
board  report  for  all  the  board  members  to  sign. 

11)  Approval  cf  board  report  -  The  signed  hoard 
report  is  submitted  to  the  approving  authority 
for  approval. 

12)  Signing  of  the  Change  Order  -  The  approving 
authority  signs  the  Change  Order  for  the 
government. 

13)  Contractor  sent  Change  Order  -  The  signed  Change 
Order  is  sent  to  the  contractor. 

111. 8  Progress  Payments  -  Periodically  the  contractor  will 
submit  a  reguest  for  a  progress  payment  to  the  CS.  The 
CS  will  obtain  an  endorsement  from  the  lead  engineer  on 
the  reguest.  Based  upon  the  lead  engineer's  endorsement 
and  upon  the  CS's  own  knowledge  of  the  progress  cf  the 
contractor,  the  CS  will  forward  the  reguest  for  payment 
to  the  proper  government  disbursing  office. 

111. 9  Disputes,  errors  and  omissions,  design  deficiencies, 
A-E  liability  -  The  Contracting  Officer,  CS,  lead 
engineer,  and  the  contractor  will  be  involved  in  the 
resolution  of  these  matters.  These  matters  are  normally 
resolved  at  this  low  level  but  may  progress  through  a 
complex  process  leading  ultimately  to  court  action  if 
necessary. 

111. 10  Final  Payment  -  When  all  design  work  has  been 
completed  and  accepted  by  the  government,  the  contractor 
will  submit  his  reguest  for  the  final  contract  payment. 
This  payment  is  processed  in  a  similar  manner  as 
progress  payments  except  that  the  contractor  is  paid  the 
full  remaining  balance  of  the  contract  fee  with  no 
contingency  withheld. 
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III.  11  Contractor  Release  -  The  contractor  is  released  from 
the  provisions  of  the  contract  once  all  work  has  been 
completed  and  final  payment  has  been  made. 

III.  12  A-E  Performance  Report  (DD  14  13)  -  The  A-E 
performance  report  is  a  summary  of  the  contractor's 
performance  during  the  life  of  a  particular  contract. 
The  CS  will  require  the  lead  engineer  to  fill  out  the  DD 
1413.  This  report  wiU  remain  in  the  contractors  file 
for  future  reference  on  other  contract  considerations. 
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V.  BEflUIREHENTS  DETERMINATION 

A.   SHY  AN  AUTOHATED  SYSTEM? 

The  NAVFAC  history  on  Automated  Data  Processing  as 
mentioned  earlier  goes  back  to  the  1950fs.  ADF  has  progres- 
sively proven  to  be  a  more  advantageous  tool  to  use  in  the 
area  of  facilities  management.  The  Naval  Facilities  System 
has  teen  built  around  the  concepts  of  ADP  and  the  emerging 
technologies  of  the  computer  revolution.  One  goal  of  the  NFS 
is  to  extend  the  management  resources  available  to  the  field 
activities.  This  process  of  distributing  the  ADP  capabili- 
ties is  evolutionary  in  nature  with  the  EFDs  becoming 
increasingly  more  ADP  oriented.  The  next  phase  of  the  evolu- 
tion is  to  reach  the  commands  and  field  activities  supported 
by  the  EFD.  Several  of  the  EFDs  have  begun  to  provide  the 
field  activities  with  computer  hardware  and  software  which 
will  enable  them  to  develop  applications  on  the  local  level 
as  well  as  communicate  directly  with  the  EFDs.  Most  of  the 
communications  planned  will  reguire  use  of  commercial  tele- 
communication lines  for  distributed  processing.  Unlike  field 
activities  in  the  continental  United  States,  overseas  activ- 
ities have  problems  with  this  form  of  communication.  The 
costs  and  reliability  factors  as  well  as  protocol  complica- 
tions make  transoceanic  telecommunication  of  data  imprac- 
tical at  this  time.  These  activities  must  depend  therefore 
on  local  independent  computer  systems. 

Automation  is  not  appropriate  for  every  situation.  For 
some  processes,  total  automation  can  be  achieved  and  will 
result  ir  many  benefits,  while  other  processes  do  not  lend 
themselves  to  automation  and  should  remain  manual.  The  8-E 
contracting  process   falls  in   the  middle   of  the   spectrum. 
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There  are  several  benefits  the   ROICC  can  gain  by  automating 
portions  of  the  process.  Consider  the  following: 

Time  Savings  -  The  A-E  management  procedures  require  a 
sizeable  amount  of  correspondence,  reports  and  stan- 
dard memorandums.  In  an  automated  system  form, 
letters,  reports  and  memorandums  are  required  to 
only  be  written  one  time.  Form  correspondence  such 
as  this  only  requires  that  unique  information  be 
inputted.  This  input  can  be  made  either  from  a  data- 
base or  in  response  to  on-line  queries.  In  advanced 
electronic  office  environments,  much  of  the  in- house 
correspondence  can  be  sent  via  electronic  mail 
producing  time  savings  for  both  staff  and  managerial 
personnel.  In  considering  the  time  required  to 
locate  information  in  a  file,  a  computer  based 
system  utilizing  a  database  management  system  can 
provide  the  information  by  simply  responding  to  a 
query.  The  computer  will  locate  the  information  as 
opposed  to  an  individual  having  to  manually  look 
through  a  physical  file. 
Accuracy  -  There  is  a  potential  for  greater  accuracy. 
Once  the  data  is  entered  into  the  system  in  the 
proper  format,  it  is  not  necessary  to  reenter  it. 
This  reduces  the  number  of  times  the  data  needs  to 
be  physically  handled.  Selective  user  interfaces 
and  error  reducing  screen  formats  can  aid  greatly  in 
reducing  the  number  of  data  entry  errors. 
Data  Collection  -  Methods  for  collecting  the  data  can  be 
much  faster  than  manual  systems.  User  interfaces  can 
te  designed  to  prompt  the  user  for  the  data. 
Properly  designed  prompts  and  input  screens  remove, 
in  a  number  of  cases,  any  questions  staff  personnel 
have  regarding  the  proper  data. 
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Data  Storage  -  Manual  systems  require  the  collection  of 
a  high  volume  of  redundant  data.  Computer  based  data 
storage  can  utilize  database  management  systems 
which  will  greatly  reduce  the  need  for  redundant 
data.  As  mentioned  earlier,  data  in  one  database  can 
be  utilized  to  satisfy  more  than  one  requirement. 
This  also  reduces  the  size  of  the  data  storage.  As 
an  example,  in  the  contract  process,  the  name  of  a 
contractor  normally  appears  on  most  of  the  coctract 
documentation.  With  a  database  management  system, 
the  storage  of  this  information  would  cnly  be 
required  once.  Follow-on  reports  or  correspondence 
could  be  provided  the  contractor's  name  from  the 
database. 

Personnel  Turnover  -  In  many  cases  an  automated  system 
can  ease  the  problems  associated  with  the  turnover 
of  personnel.  The  automated  system  if  properly 
designed  can  guide  new  personnel  in  the  work 
process.  With  built-in  help  facilities,  the  computer 
can  be  referenced  when  questions  arise.  Also  for 
data  entry,  set  formats  provide  the  new  personnel 
with  a  template  for  input  process,  removing  seme  of 
the  ambiguity  of  a  new  system. 

Costs  -  Most  improvements  to  a  process  result  in  cost 
savings.  Computer  based  systems  are  no  exception  if 
they  are  properly  designed  to  fit  both  the  organiza- 
tional needs  and  the  process.  Cost  savings  are  seen 
in  personnel,  supplies  (less  paper  in  some  systems), 
and  time  savings  from  data  entry,  storage,  and 
retrieval. 
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B.       THE    CONPUTER-BASEE    ENVIRONMENT 

For  the  proposed  automated  A-S  contract  management 
process  to  be  effective,  it  should  provide  the  benefits 
described  above.  Aron  [Ref.  8:  pp.  213-236]  describes  three 
levels  cf  information  system  design  for  organizational 
information   systems.    The    levels   are: 

1)  simple    data    processing    system 

2)  integrated   file-oriented   data    processing   system 

3)  management    information   system 

A  fourth  level  would  be  information  resources  management 
systems  (IRMS)  ,  a  concept  on  the  current  edge  of  information 
systems  technology.  Each  of  the  higher  level  systems 
include  the  elements  of  the  lower  level  systems  since  the 
development  of  the  systems  from  the  first  to  the  fourth  has 
occurred  in  an  evolutionary  process.  Let's  consider  each 
level  individually  in  relationship  to  the  A-E  contract 
management  process. 

1 .   Simple  Data  Processing  System 

The  simple  data  processing  system  consists  of  a 
number  of  independent  transaction-oriented  tasks  which 
summarize  inputs  to  produce  reports.  The  ROICC  may  want  to 
know  at  the  conclusion  of  the  fiscal  year  how  many  contracts 
were  awarded  for  A-E  services.  A  simple  data  processing 
system  approach  to  this  request  is  shown  in  Figure  5.1. 
During  the  year,  as  each  contract  is  awarded,  an  input  could 
be  made  into  a  computer  which  would  give  the  data  for  the 
contract  such  as  the  contract  number,  title,  A-E  firm  and 
the  fee.  A  program  cculd  be  written  to  take  this  input  and 
produce  a  report  at  the  end  of  the  year  which  would  summa- 
rize the  number  of  contracts  and  the  total  dollar  amount  of 
fees  awarded.  This  same  approach  could  be  made  for  a  number 
of  desired  reports.   The  disadvantage  of  this  type  of  system 
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Figure  5.1    Siaple  Data  Processing. 

is  that  the  reports  are  historical  in  nature  and  tend  to 
provide  cnly  record  type  information.  Simple  data  processing 
systems  which  produce  historical  data,  do  not  lend  them- 
selves to  the  day  to  day  dynamic  management  requirements  of 
the  ECICC. 

2  •   Integrated  File-Oriented  Da ta  Processing  System 

Most  shortcomings  of  the  data  processing  system  are 
overcome  by  the  development  of  the  integrated  file-oriented 
data  processing  system.  The  integrated  file-oriented  data 
processing  system  structures  data  such  that  facts  can  be 
extracted  according  to  many  different  criteria.  A  contractor 
information  system  maintained  by  the   ROICC  can  contain  data 
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on  contractors  who  either  do  business  with  the  Government  or 
who  desire  to  be  considered  for  upcoming  contracts.  The  data 
is  stored  in  a  series  of  files  made  up  from  information  the 
contractor  has  submitted  via  the  SF  254  and  possibly  the  SF 
255.  These  forms  provide  demographic  information  on  the 
contractor  as  well  as  the  composition  of  the  firm  by  disci- 
pline and  a  short  concise  history  of  the  firm's  past 
contract  experience.  The  ROICC  utilizing  an  integrated  file- 
oriented  data  processing  system  can  determine  for  example 
which  contractors  on  record  have  the  proper  mix  of  engi- 
neering disciplines  to  perform  a  certain  contract.  This 
would  be  accomplished  as  shown  in  Figure  5.2.  The  data  from 
the  SFs  would  be  inputted  to  database  files  as  the  forms  are 
received  by  the  ROICC.  A  series  of  program  would  be  used  by 
a  supervisory  program  to  select  and  extract  the  needed 
information  from  the  proper  data  files  in  the  database.  The 
output  would  be  formatted  by  one  of  the  programs  in  the 
series  and  produced  either  as  a  newly  created  file  or  as  a 
hardccpy  report  or  as  both. 

3 .   Management  Information  S _ys t e m 

The  MIS  adds  another  block  to  the  information  system 
structure.  The  MIS  adds  the  foreknowledge  of  what  decisions 
must  be  made  by  the  ROICC  in  managing  the  contracting 
process.  The  MIS  is  an  integrated  system  for  providing 
information  to  support  planning,  control,  and  the  operation 
of  the  RCICC  shop.  Figure  5.3  shows  the  basics  of  a  typical 
MIS.  The  MIS  combines  the  data  bases  of  the  integrated 
file-oriented  system  with  a  database  of  inference  models  and 
models  for  evaluation  criteria.  Application  programs  kept  on 
file  are  utilized  to  draw  data  from  the  three  databases  to 
assist  the  ROICC  in  making  decisions.  The  ROICC  using  a  MIS 
could  be  guided  to  the  proper  reports  required  by  a  certain 
contract  type  or  size.   The   MIS  would  evaluate  the  contract 
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Figure  5.2   Integrated  File-Oriented  Processing. 

based  on  the  size  of  the  contract  fee  to  determine  which 
approvals  would  be  required.  The  MIS  would  make  tnis 
requirement  known  and  then  would  proceed  to  collect  the 
information  from  the  main  database  to  create  the  report  and 
produce  it  either  for  viewing  on  a  CRT  or  in  hardcopy. 

** •   Information  Resource  Management  System 

The  Information  Resource  Management  System  (IRMS)  is 
the  current  technology  in  information  systems.  The  system  is 
the  convergence  of  several  information  technologies,  data 
processing,  communications  and  the  automated  office.  In  the 
futare,  IRMS  will  permit  the  ROICC  to  teleconference  with 
the  EFD  and  possibly  permit  the  Award  Board  to  interview  the 
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Figure  5.3    Hanageaent  Information  System. 

contractor  via  teleconferencing.  Host  transactions  in  the 
contracting  process  would  be  accomplished  without  paper.  All 
draft  SOWs,  drawings  and  payment  requests  would  be  trans- 
mitted electronically.  The  futuristic  IRHS  would  extend  the 
HIS  capabilities  so  that  Decision  Support  Systems  would  be 
available  to  the  ROICC  from  EFD  resources. 

C.   ROICC  A-E  CONTRACTING  HIS 

The  IRHS  is  technologically  in  the  future  for  the  ROICC 
and  for  NAVFAC  as  a  whole.  The  data  processing  system  and 
the  integrated  file  oriented  processing  systems  seem  only  to 
automate  a  currently  manual  system  rather  than  provide  an 
improved  management  tool.    The  complete  contract  management 
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function  of  the  ROICC  which  includes  A-E  and  construction 
contracting  management  would  be  well  supported  by  a  MIS.  The 
A-E  contract  management  process  would  be  only  part  of  that 
system. 

The  system  to  support  the  ROICC  MIS  should  enable  the 
ROICC  to  do  basic  word  processing,  database  management,  and 
run  applications  to  interface  the  database  and  the  applica- 
tion programs.  The  size  of  the  system  would  depend  primarily 
on  the  size  of  the  contract  management  task.  The  applica- 
tions could  consist  cf  different  modules:  1)  to  handle 
report  and  letter  generation;  2)  to  track  the  individual 
contract  phases;  3)  to  track  the  contract  workload;  and  4) 
to  run  rule  based  modules  to  assist  the  ROICC  in  deciding 
where  and  when  to  apply  various  regulations.  TFith  the  addi- 
tion of  communication  technologies,  the  system  could  be 
connected  to  the  engineering  department  so  that  requirements 
such  as  SOWs  and  government  estimates  could  be  transmitted 
electronically.  Further  communication  capabilities  would 
enable  tie  ROICC  to  send  reports  and  copies  of  contracts  to 
the  EED  electronically. 

D.   PROPOSED  A-E  CONTRACTING  SYSTEM 

The  following  three  chapters  present  a  proposed  auto- 
mated A-E  Contract  Management  System  beginning  with  the 
pre-negotiation  phase  and  concluding  with  the  post-award 
phase.  The  proposed  system  is  based  on  the  idea  of  using  a 
micro-computer  and  running  commercially  available  software 
to  develop  application  modules.  The  concepts  used  to 
develop  the  framework  of  the  system  are  those  discussed 
above.  The  approach  taken  in  the  proposal  is  not  the  only 
one  that  will  produce  a  useable  automated  A-E  MIS.  It  will 
provide  the  field  with  a  useful  management  tool  at  a  minimal 
cost   through   available   current  technology.    As   will   be 


56 


discussed  later,  tie  hardware  and  software  utilized  to 
implement  the  proposed  system  can  be  used  by  the  field 
activity  in  other  ways.  As  an  example  of  how  such  a  system 
could  be  developed  and  might  function,  one  major  module  of 
the  proposed  system,  the  Contractor  Information  System 
(CIS)  ,  has  been  developed  and  is  presented  in  Appendix  A. 


57 


VI.  AUTOMATICS  OF  THE  PREzNEGOTIATION  PHASE 

The  Pre-Negotiaticn  Phase  will  be  the  initiation  phase 
of  the  majority  of  the  automation  of  the  entire  management 
information  process.  Some  functions  for  this  phase  will  also 
be  carried  into  the  second  and  third  phases.  Each  step  will 
be  investigated  for  possible  automated  procedures  in  the 
areas  of  applications,  report  generation  and  database  appli- 
cations. As  will  be  seen,  many  of  the  automation  procedures 
will  require  the  interface  of  these  three  areas  for  effec- 
tive building  of  management  tools  and  improvements  for  the 
office  staff. 

A.   BEQUEST  FOB  CONTRACT  (I.  1) 

The  contracting  officer  after  receiving  the  request  for 
contract  can  initiate  two  automated  management  tools,  the 
phase  I/II  tracking  database  and  the  contract  file.  The 
tracking  database  tracks  the  administrative  contracting 
steps  of  phase  I  and  II  and  is  driven  by  an  application 
module  which  guides  the  user  through  the  proper  control 
measures.  The  database  would  contain  a  listing  of  all  the 
contracting  steps  with  an  estimated  completion  time  calcu- 
lated automatically  by  the  driver  application.  The  base  of 
the  completion  times  would  be  provided  by  the  contracting 
officer.  This  aspect  cf  the  tracking  system  would  permit  the 
contracting  officer  to  vary  the  times  based  on  the  condi- 
tions at  hand  (i.e.  year-end  obligations,  predetermined 
performance  criteria,  etc.).  As  the  steps  are  completed,  the 
appropriate  dates  car  be  entered  into  the  database  hy  an 
automated  timestamp. 
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Another  feature  cf  the  tracking  system  is  the  tickler 
function.  This  function  permits  the  user  to  enter  the 
current  date  and  be  given  a  listing  of  all  actions  which  are 
due  to  te  completed  en  that  day  and  present  a  listing  of  the 
delinquent  actions  and  signify  if  there  is  a  comment  in  the 
file  explaining  the  variance.  Since  delays  can  be  expected, 
provisions  exist  for  the  user  to  adjust  the  schedule.  A  log 
in  the  database  will  be  maintained  to  record  adjustments  for 
historical  purposes. 

The  second  management  tool  is  the  contract  file  which  is 
simply  an  electronic  file  of  contract  documents  and  check- 
lists. The  contract  file  is  not  a  static  depository  of 
electronically  produced  documents,  but  along  with  specific 
application  programs  will  become  the  most  extensively  used 
management  tool  for  the  CS  and  contracting  officer.  The 
checklists  in  the  file  will  aid  the  CS  in  the  contracting 
process.  Many  documents  will  be  placed  in  this  file  by 
various  application  programs.  The  file  will  be  updated  on 
many  occasions  autonatically  by  the  application  programs. 
Access  to  the  file  is  limited  by  procedures  described  below. 

E.   CCNTEACT  SPECIALIST  ASSIGNED  (1.2) 

The  contracting  officer  will  maintain  a  database  of  the 
CSs  in  the  organization  and  the  contracts  they  are  assigned. 
He  will  update  the  database  as  a  new  assignment  is  made  as 
well  as  update  the  contract  file  to  indicate  the  CS 
assigned.  This  update  to  the  contract  file  is  part  of  the 
security  measures  of  the  system.  Only  certain  personnel 
determined  by  the  contracting  officer  can  access  the 
contract  file  for  a  particular  contract.  Each  CS  and  staff 
person  is  assigned  a  personal  password.  To  gain  entry  to 
specific  files  the  person  desiring  entry  must  first  get 
through   a  password   checking  module.    Limitations  in   file 
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entry  can  be  no  access,  read  only  access  or  full  access 
which  allows  both  read  and  write  access.  The  access  tc  the 
file  can  be  changed  at  anytime  by  the  contracting  officer  or 
a  designated  assistant. 

The  first  form  letter  from  the  report  file  is  initiated 
upon  the  assignment  of  the  CS.  The  contracting  officer 
initiates  a  letter  to  the  customer  informing  him  of  the 
acceptance  of  the  contract  request,  the  CS  assigned,  the 
contract  number  and  also  the  need  for  a  complete  SOF  and 
government  estimate  (if  the  customer  is  the  engineering 
department,  otherwise  the  CS  will  ensure  that  the  government 
estimate  is  developed)  .  The  basic  form  of  the  letter  is 
contained  in  a  report  generator  file.  This  file  is  a  collec- 
tion of  all  the  rercrts  and  letters  required  during  the 
entire  contract  process.  The  user  is  given  the  option  when 
using  the  form  letters/reports  to  input  the  information 
using  a  word  processor  type  entry  or  to  let  the  system 
extract  the  information  from  the  various  databases  in  the 
system.  For  example,  the  letter  to  the  customer  can  ofctain 
the  contract  number  and  the  CS  assigned  from  the  contract 
file.  The  contracting  officer  needs  only  to'  identify  the 
correct  contract  file. 

C.   DEVELOPMENT  OF  STATEMENT  OF  WORK  (1.3) 

The  SOW  may  be  written  by  the  customer  using  a  word 
processor  and  transmitted  to  the  contract  office  via  modem 
or  by  sending  a  copy  on  a  floppy  disk  to  the  CS.  The  CS  can 
proceed  to  use  a  word  processor  to  proof  the  SOW  and  make 
the  appropriate  changes  then  return  the  SOW  to  the  customer 
in  a  similar  manner.  If  the  SOW  is  electronically  produced 
it  can  be  placed  into  the  contract  file.  If  not,  a  duplicate 
physical  file  will  have  to  be  maintained  for  any 
non-electronically  produced  documents. 
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D.  DETAILED  GOVERNHEHT  ESTIMATE  (1.4) 

An  application  module  maintained  by  the  contracting 
staff  will  be  available  for  use  by  the  engineering  staff  to 
develop  the  estimates.  The  module  will  permit  the  estimator 
to  access  a  database  of  standard  costs  for  various  labor 
categories.  A  cost  estimate  worksheet  will  be  provided  the 
estimator  from  the  reports/letters  file  which  permits  the 
estimator  to  build  the  estimate  from  the  labor  costs  data- 
base. The  estimator  application  module  allows  the  estimator 
to  enter  a  labor  class  and  estimated  effort  from  which  the 
total  cost  for  that  labor  class  will  be  calculated.  The 
module  will  supply  the  current  applicable  overhead,  Gf-A,  and 
other  fees  and  calculate  the  bottom  line  figures.  The  esti- 
mator is  provided  tie  flexibility  to  change  any  estimate 
entered  and  request  another  calculation  of  the  total.  The 
estimate  can  then  be  electronically  transmitted  to  the  CS . 

E.  REQUIRED  CLEARANCES  AND  APPROVALS  (1-5) 

Based  on  the  provided  government  estimate,  the  ■  CS  can 
utilize  a  rule-based  decision  module  to  determine  which 
clearances  and  approvals  are  required  for  the  procurement 
action.  The  ruled-tase  is  maintained  by  the  contracting 
staff  to  reflect  current  contracting  regulations.  The  CS 
would  be  guided  through  a  series  of  possible  requirements. 
If  the  module  determines  a  clearance  or  approval  is 
required,  the  CS  determines  if  the  report  or  letter  should 
be  prepared.  If  the  report/letter  is  to  be  prepared,  the 
report/letter  file  is  accessed  for  the  proper  format  and  the 
information  required  can  be  obtained  from  the  various  data- 
bases or  alternately  may  be  provided  by  the  CS.  In  the 
former  case,  the  CS  will  be  prompted  for  the  information  and 
be  given  the  format  for  the  information  if  a  specific  format 
is  reguired.  Copies  of  any  correspondence  will  be  placed  in 
the  contract  record  data  file. 
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F.  SMALL  BUSINESS  SET  ASIDE  RECOMMENDATION  (1.6) 

This  recommendation  will  be  a  part  of  the  rule-based 
module  described  above.  Once  the  decision  is  made,  the 
contract  file  will  be  updated  to  reflect  the  decision. 

G.  COMMERCE  BUSINESS  DAILY  SYNOPSIS  (1.7) 

The  CS  will  call  up  from  the  report/letter  file  the 
format  for  the  letter  to  the  Commerce  Business  Daily.  The 
basic  form  such  as  tie  address  and  standard  verbiage  will  be 
on  the  letter.  The  CS  using  a  word  processor  can  fill  in  the 
body  of  the  letter  with  the  information  concerning  the 
proposed  contract  then  print  a  hard  copy  and  mail  it  to  the 
CBD.  A  copy  of  the  CEE  announcement  letter  will  be  placed  in 
the  contract  file. 

H.   LOGGING  OF  SF  254  AND  SF  255  (1-8) 

The  SF  254/255  provides  information  on  the  contractor 
and  the  firm's  history  of  performance.  The  CS  or  a  staff 
assistant  will  enter  the  summary  information  from  the  forms 
into  the  Contractor  Information  System  (CIS)  database.  The 
application  module  permits  a  number  of  functions  to  be 
performed  on  the  CIS  database.  These  include  adding, 
changing,  deleting,  viewing  and  printing  of  reports.  A 
sample  of  an  operational  CIS  application  module  is  presented 
in  Appendix  A.  An  important  aspect  of  the  design  of  this 
application  module  is  the  data  design  and  description.  The 
Contractor  Information  System  is  a  NAVFAC  system  included  as 
part  of  the  NFS.  The  data  collected  in  this  module  must  be 
as  near  as  possible  to  the  data  format  and  descriptions  as 
used  in  the  NFS.  This  compatibility  will  insure  that  when 
future  transmission  of  information  between  the  EFD  or  FACSO 
becomes  a  reality,   there  will  be  minimal  interface  problems 
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and  adjustments.  The  details  of  the  CIS  are  discussed  in  the 
Appendix  A. 

The  CS  or  contracting  officer  can  use  the  CIS  for  devel- 
oping bidder's  lists  for  specific  contract  requirements. 
This  is  especially  important  to  have  in  the  advent  of  urgent 
design  projects  which  must  be  accomplished  under  exceptional 
circumstances.  Contractors  who  have  previously  submitted  the 
SF  254  need  not  be  reentered  into  the  CIS.  Their  file  will 
only  require  updating.  Under  normal  conditions,  most 
contracting  offices  have  a  stable  base  of  contractors  who 
continuously  bid  on  contracts.  This  reduces  the  number  of 
first  time  entries  into  the  CIS. 

I.   BOABE  APPOINTMENT  LETTERS  (1.9) 

A  database  is  maintained  listing  the  eligible  board 
members  and  the  current  boards  they  are  sitting  on  as  well 
as  the  last  concluded  board  they  sat  on.  A  board  member 
selection  module  will  permit  the  selection  of  the  members 
from  the  list  simply  by  indicating  an  identifier  (number  or 
letter).  The  module  will  then  access  the  reports/letters 
file  and  extract  tire  notification  letter  for  the  board 
members.  The  letters  will  be  printed  out  automatically  or 
transmitted  to  the  member's  office  if  electronic  mailing 
systems  are  in  use.  The  contract  file  will  be  automatically 
updated  to  indicate  the  pre-selection  board  members. 

J.       PEE-SEIECTION  (1.10) 

The  reports/letters  file  contains  a  form  pre-selection 
board  letter.  This  form  letter  can  be  used  by  the  Board  to 
record  the  Board  meeting  results.  The  CS  upon  receiving  the 
results  of  the  board  and  an  authorized  signature  ccpy  of  the 
board  report  will  update  the  contract  file  with  a  copy  of 
the  board  report. 
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All  during  the  pre-negotiation  phase  the  contract 
tracking  system  has  teen  operational.  The  updates  to  this 
tracking  system  can  either  be  performed  automatically  by  the 
master  module  of  the  contracting  MIS  or  by  the  CS  as  the 
steps  are  completed.  This  tracking  system  is  carried  through 
to  the  Negotiation  Phase. 
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VII.  AUTOMATION  OF  THE  NEGOTIATION  PHASE 

Transition  to  the  second  phase  of  the  A-E  contracting 
phase  frcm  the  first  phase  is  transparent  to  the  user.  The 
same  proposed  tracking  system,  databases  and  the  reports/ 
letters  file  are  used.  In  fact  the  main  driver  program  for 
the  application  modules  is  still  in  use. 

A.  INTERVIEW  LETTERS  (II. 1) 

The  pre-selecticn  board  report  produced  the  slate  of 
contractors  to  be  considered  in  the  interviewing  process  of 
the  negotiation  phase.  The  names  of  these  contractors  were 
placed  in  the  contract  file  as  the  closing  action  of  the 
first  phase.  The  CS  can  retrieve  the  form  interview  letter 
from  the  reports/letters  file.  The  contractors  names  can  be 
extracted  from  the  contract  file.  The  addresses  of  the 
selected  contractors  can  be  extracted  from  the  CIS  database. 
The  CS  will  more  than  likely  schedule  the  interviews  around 
the  availability  of  the  board  members  and  the  contractors. 
Once  a  schedule  has  been  established,  the  CS  will  note  the 
times  and  place  of  the  interviews,  print  the  letters  and 
send  them  to  the  contractors.  A  schedule  of  the  interviews 
will  be  maintained  in  the  contract  file. 

B.  INTERVIEW  OF  THE  A-E  FIRMS  (II. 2) 

Several  items  can  be  included  in  this  step  of  the 
process  but  all  the  automated  options  are  at  the  discretion 
of  the  contracting  officer.  A  form  interview  evaluation 
sheet  can  be  maintained  in  the  reports/letters  file.  This 
type  of  uniform  evaluation  focus  can  ensure  that  all  the 
board  members  evaluate  the  proper  aspects  of  the  contractor. 
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This  fcrm  would  be  used  in  conjunction  with  the  predefined 
evaluation  criteria.  The  evaluation  would  be  a  standard  form 
used  for  all  contract  interviews.  A  listing  of  instruction 
to  the  interviewers  can  also  be  prepared  and  maintained  in 
the  file.  If  a  standard  evaluation  algorithm  is  used  by  the 
board  to  determine  the  best  qualified  contractor,  a  module 
can  be  provided  to  calculate  the  results.  While  this  would 
provide  an  analytically  determined  best  qualified 
contractor,  it  is  probably  only  a  good  starting  pcint  for 
discussion  by  the  selection  board. 

C.  SEIECTION  OF  A  CCSTRACTOR  (II. 3) 

Once  the  board  determines  from  the  interviews  who  the 
best  qualified  contractor  is,  a  board  report  must  be 
produced  for  approval  of  the  selection.  Again  the  CS  or  the 
head  of  the  board  can  retrieve  a  form  letter  from  the 
reports/letters  file.  The  heading  and  boilerplate  informa- 
tion will  already  be  en  the  letter  and  the  CS  can  use  a  word 
processor  to  fill  in  the  remainder  of  the  letter  based  on 
the  findings  of  the  board.  After  the  selection  has  been 
approved  by  the  approval  authority,  the  contract  file  will 
again  be  updated  by  the  CS. 

D.  REQUEST  FOR  FEE  PROPOSAL  (II. 4) 

The  selected  contractor  is  supplied  with  a  standard 
government  estimate  form.  This  ensures  consistency  between 
the  format  of  the  contractors  estimate  and  the  government 
estimate.  The  estimation  form  and  the  letter  to  forward  the 
form  to  the  contractor  are  both  contained  in  the  reports/ 
letters  file.  The  CS  can  add  any  instructions  and  comments 
that  are  deemed  appropriate  for  the  particular  contract. 

If  the  contract  is  of  sufficient  size,  various  forms  and 
certificates   will   be   required   of   the   contractor.    A 
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rule-based  module  will  again  be  employed  to  assist  the  CS  in 
determining  which  forms  and  certificates  are  required  of  the 
contractor.  The  module  will  automatically  retrieve  any 
required  forms  and  will  also  signify  which  certificates  are 
necessary. 

E-   EECEIPT  OF  THE  FEE  PROPOSAL  (II. 5) 

Once  the  fee  proposal  is  received  by  the  CS,  the 
contract  file  is  updated  to  show  the  receipt.  The  lead  engi- 
neer (on  the  board)  will  review  and  compare  the  estimates.  A 
spreadsheet  type  module  could  be  developed  for  use  in  this 
comparison  process.  The  module  would  evaluate  the  differ- 
ences in  particular  items  on  the  estimates.  This  however  is 
not  recommended  since  in  most  instances  the  estimates  will 
vary  in  the  classes  cf  labor  that  will  be  used.  It  would  be 
comparing  dissimilar  items  which  is  no  comparison.  The 
expense  of  development  and  the  overhead  of  maintaining  such 
a  module  probably  could  not  be  justified. 

The  amount  of  the  fee  may  require  that  other  clearances 
be  obtained.  A  rule-based  module  will  again  be  used  to 
assist  the  CS  in  identifying  the  clearances  needed.  If  forms 
are  needed  they  will  be  produced  along  with  a  forwarding 
letter  to  the  contractor. 

F.   PEE-NEGOTIATIOH  (II. 6) 

No  automation  is  needed  in  this  step  except  for  possibly 
the  writing  of  memorandums  using  a  word  processor.  The 
letter  would  be  a  record  of  any  pre-negotiation  discussions 
the  CS  or  engineers  have  with  the  contractor.  These 
documents  would  be  filed  in  the  contract  file. 
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G.   NEGOTIATION  BOAR!  MEETING  (II. 7) 

The  negotiation  board  report  form  letter  is  maintained 
in  the  reports/letters  file.  The  CS,  upon  completion  of  the 
negotiations  with  the  contractor  and  agreement  between  the 
board  members,  will  prepare  the  board  report  using  a  word 
processor  to  fill-in  the  form  letter.  The  letter  would  then 
be  forwarded  to  the  approval  authority  for  signature. 

H.   NEGOTIATION  BOARD  REPORT  APPROVAL  (II- 8) 

Since  this  function  occurs  outside  of  the  contracting 
office  in  most  cases,  no  automation  is  required.  However,  if 
electronic  mail  is  in  use,  the  letter  can  be  sent  through 
this  system.  Signatures  in  an  electronic  mail  system  can  be 
implemented  through  the  use  of  specially  assigned  password 
type  keys.  For  example,  unique  control  sequence  entries  into 
the  designated  signature  block  of  the  letter  can  be  recorded 
but  not  seen.  The  tail  or  head  of  the  control  sequence  can 
contain  the  visible  initials  or  name  of  the  person  whose 
unseen  signature  is  present.  A  module  can  be  used  in  the 
system  to  decipher  the  signature  for  verification  purposes. 

I.   CONTRACT  AWARD  (II. 9) 

The  approved  contract  award  report  is  filed  in  the 
contract  file.  This  step  requires  the  CS  to  build  the 
actual  contract  by  using  an  on-line  file  of  standard  provi- 
sions and  special  previsions.  The  CS  can  place  all  the 
required  contract  documentation  in  a  single  working  file  and 
upon  completion  have  the  the  contract  printed.  The 
contracting  office  ccpy  of  the  contract  need  not  be  printed 
since  it  will  be  placed  in  the  contract  file  and  can  be 
reviewed  at  any  time  by  the  contracting  staff.  The  complete 
contract  can  then  he  forwarded  to  the  contractor  for 
signature. 
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VIII.  AUTOMATION  QF  111  £OST^AWARD  PROCESS 

The  end  of  the  second  phase  is  also  the  end  of  the 
proposed  tracking  system  used  in  the  first  two  phases.  A  new 
proposed  tracking  system  is  initiated  at  the  beginning  of 
the  third  phase  of  the  A-E  contracting  process  which  is 
similar  to  previous  one  with  the  exception  being  the  things 
that  are  tracked.  The  tracking  database  contains  the 
project  number  and  title  (relating  to  any  specia]  project 
designs  that  are  being  accomplished),  contract  number,  A-E's 
name  and  number,  fee  for  the  design,  current  working  esti- 
mate, engineer  in  charge  of  the  design  effort  and  the  award 
date  of  the  contract.  Dates  to  be  tracked  are  the  scheduled 
and  actual  submittal  dates  for  the  30%,  60%,  90%,  and  1003 
from  the  contractor  as  well  as  the  comparable  dates  for  the 
government  review  process  of  the  contractor's  work. 

This  tracking  system  is  initiated  by  the  CS  with  the  aid 
of  a  module  which  actually  creates  the  database  from 
existing  databases  and  the  contract  file  once  the  CS  signi- 
fies which  contract  is  to  be  tracked.  The  tracking  system 
can  be  used  by  the  contracting  officer  or  the  CS  tc  see 
which  actions  are  reguired  to  be  completed  on  a  certain  day. 
The  system  also  provides  a  profile  of  the  actions  due  for 
completion  over  a  specified  period  of  time.  This  feature 
will  be  most  helpful  at  peak  operating  period  such  as  the 
end  of  the  fiscal  year. 

A.   NOTIFICATION  LETTERS  (III.  1) 

The  CS  utilizes  the  reports/letters  file  to  retrieve  the 
notification  letter  format.  In  most  cases,  this  letter  is 
completely   standardized  with  the   only   information  tc  be 
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added  being  the  names  of  the  receiving  contractor  and  the 
contractor  who  was  awarded  the  contract.  The  CS  can  either 
put  these  in  using  a  word  processor  or  the  system  can 
perform  this  automatically  by  the  CS  indicating  which 
contractor  was  awarded  the  contract.  The  remainder  of  the 
information  can  be  obtained  from  the  contract  file  where  all 
the  considered  contractors  names  and  addresses  are  listed. 
Copies  of  these  letters  are  not  retained  but  a  notation  is 
made  in  the  contract  file  that  the  letters  were  sent. 

B.   INDIVIDUAL  PEOCUBEMENT  ACTION  (DD  FOBM  350)   (III. 2) 

The  DD  350  reports  to  higher  commands  information 
concerning  individual  procurements.  It  is  to  be  submitted 
the  day  after  a  contract  has  been  awarded.  An  application 
module  is  provided  tc  permit  the  CS  to  supply  the  informa- 
tion for  the  completion  of  the  report.  The  format  for  the 
interface  with  the  icdule  can  take  on  many  forms  depending 
upon  the  design  of  the  system.  One  interface  would  be  for 
the  CS  to  be  prompted  for  the  information  that  is  not 
already  available  in  the  contract  file  or  the  Contractor 
Information  System  database.  For  information  which  already 
exists  the  CS  can  verify  the  correctness.  Once  the  informa- 
tion is  gathered,  a  standard  format  can  be  used  from  the 
reports/letters  file  to  print  the  form.  An  enhancement  would 
be  to  transmit  the  form  electronically  to  either  the  EFD  or 
to  NA7FAC  directly  if  the  communication  resources  are  in 
place.  A  copy  of  the  report  would  be  placed  in  the  contract 
file. 

The  DD  Form  1057  is  a  monthly  summary  of  contracts 
awarded  by  the  activity.  A  similar  procedure  can  be  used  by 
the  contracting  staff  to  produce  this  report.  As  systems 
evolve,  reports  such  as  the  DD  350  and  1057  will  become 
obsolete.   The   information  required  by   the  EFD   and  NAVFAC 
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will  be  available  to  these  upper  levels  of  command  at  all 
times.  Communications  and  networks  will  exist  such  that  the 
application  modules  to  retrieve  the  information  currently 
provided  by  these  reports  will  reside  at  the  level  where  the 
information  is  required.  These  modules  will  be  able  to 
access  specially  designated  databases  at  the  field  levels 
whenever  the  data  is  desired. 

C.  OTBEE  REPORTS  (III.  3) 

As  mentioned  in  the  other  two  phases,  rule-based  appli- 
cation modules  will  determine  which  reports  are  required  for 
the  individual  contracts.  These  modules  will  indicate  the 
required  reports  and  guide  the  CS  in  preparing  them  for 
submission.  The  report  formats  themselves  will  reside  in  the 
reports/letters  file.  Any  reports  submitted  will  be  filed  in 
the  contract  file. 

D.  DISTRIBUTION  OF  CONTRACT  (III. 4) 

Copies  of  the  contract  will  be  sent  to  various  parties. 
If  the  parties  to  receive  the  copies  have  electronic  mailing 
systems,  the  copies  can  be  sent  this  way  expediting  the 
mailings  and  reducing  the  mailing  costs  as  well  as  aiding  in 
the  storage  of  such  documentation  at  the  receiving  end.  Many 
EFDs  require  a  copy  of  each  contract  awarded  so  information 
can  be  obtained  for  reference  purposes.  This  procedure  may 
change  in  the  future  as  the  information  transfer 
possibilities  are  expanded. 

I.   CCNTBACTOR  MEETIHGS  (III. 5) 

These  meetings  may  occur  for  a  variety  of  reasons  and 
all  should  be  documented.  The  engineer  or  the  CS  could  use 
the  word  processor  to  record  the   events  of  the  meeting.    A 
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copy  of  the  meeting  minutes  will  be  placed  in  the  contract 
file.  Seme  contracts,  especially  those  with  a  first  time 
contractor,  require  a  preliminary  meeting  to  discuss  stan- 
dard administrative  items.  Checklists  to  cover  the  require- 
ments cf  the  meeting  can  be  maintained  in  the 
reports/letters  file  for  use  by  the  CS  or  engineer  as  a 
guide  for  the  meetings. 

F.  DESIGN  BEVIEWS  (III. 6) 

The  tracking  system  is  the  key  management  tool  in  this 
procedure.  Other  valuable  computerized  tools  would  be  a 
database  of  the  assigned  drawing  numbers.  This  would  permit 
the  recording  of  the  drawings  numbers  and  titles.  This  data- 
base could  be  expanded  to  act  as  an  index  for  future  refer- 
ences to  the  loeatien  of  drawings  which  would  be  useful  to 
the  larger  engineering  departments.  The  documentation  which 
accompanies  the  review  process  (comment  sheets  on  submit- 
tals) can  be  maintained  in  their  basic  form  in  the  reports/ 
letters   file. 

G.  CCNTBACT  MODIFICATIONS  (III- 7) 

Contract  modifications  are  not  tracked  on  the  third 
phase  tracking  system.  A  note  is  made  on  the  tracking  system 
that  a  modification  is  taking  or  has  taken  place.  It  is 
proposed  that  a  separate  tracking  system  be  established  for 
these  modifications.  This  modification  tracking  database 
would  contain  many  of  the  data  elements  that  the  phase  I  and 
II  system  tracked  including  a  brief  description  of  the  modi- 
fication, contract  number,  dates  (estimated  and  actual)  for 
SOW  and  government  estimate  submission,  request  for  and 
receipt  cf  the  fee  proposal,  negotiation  board  meeting  and 
the  signing  of  the  change  order.  The  estimated  days  are 
generated  automatically  based  on  past  experience.  The  CS 
will  enter  the  actual  days. 

72 


Board  member  appointments  and  letters  of  notification 
are  required.  This  is  handled  utilizing  the  same  modules 
that  were  used  in  the  earlier  phases.  The  processing  of  the 
SOW  and  government  estimate  are  identical  to  step  1.3  and 
1.4.  In  essence,  this  process  follows  the  same  procedures 
as  are  followed  in  the  negotiation  phase  of  the  contract  and 
reguires  the  same  nanagement  attention.  For  open-ended 
contracts,  the  modification  process  can  be  in  progress  for 
different  proposed  changes.  This  requires  that  management  of 
the  contract  modifications  be  effective  and  accurate. 

H.   PKOGBESS  PAYMENTS  (III. 8) 

Maragement  of  the  progress  payment  process  is  most 
important  for  good  working  relations  with  the  contractor. 
Even  though  the  contracting  office  is  not  the  actual  payer 
of  the  funds,  mismanagement  of  the  request  for  payment  can 
have  damaging  effects.  A  spreadsheet  type  file  is  maintained 
for  the  contract  which  contains  the  dates  and  amounts  of 
requested  payments  as  well  as  the  date  and  amount  of  the 
actual  payments.  The  payment  data  may  be  difficult  to 
obtain  depending  on  the  arrangements  made  between  the 
contracting  office  and  the  paying  office.  This  relationship 
should  be  established  such  that  the  CS  can  obtain  accurate 
information  in  a  timely  manner. 

The  CS  receives  the  request  for  payment  from  the 
contractor.  A  standard  form  from  the  reports/letters  file 
will  be  used  by  the  CS  to  transmit  to  the  lead  engineer  the 
information  regarding  the  payment  request.  The  engineer  must 
annotate  the  form  indicating  his  approval  of  the  percentage 
complete  on  the  project.  This  percentage  is  used  to  deter- 
mine the  amount  of  tie  payment  to  the  contractor.  If  elec- 
tronic mail  is  in  use,  this  process  can  be  accomplished 
electronically.   The  final  copy   of  the  engineer's  annotated 
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copy  is  placed  in  the  contract  file.  The  spreadsheet  data- 
base is  updated  on  each  request.  An  application  module 
perforins  the  calculations  on  the  amounts  to  be  withheld  and 
amounts  to  be  paid  based  on  predetermined  standards.  The 
system  then  generates  the  proper  form  requesting  the  paying 
activity  to  pay  the  contractor  the  specified  amount  or 
transmitted  electronically  to  the  disbursing  agent. 

I.   DISPUTES,   ERRORS,   OMISSIONS,   DESIGN  DEFICIENCES,   A-E 
LIABILITY  (III. 9) 

The  actual  handling  of  these  actions  is  determin€d  at 
the  local  level.  Boards  are  often  convened  to  make  determi- 
nations. In  this  case,  the  modules  used  to  establish  board 
members  can  again  be  utilized.  Also,  some  reports  may  be 
necessary  in  certain  circumstances.  These  reports  can  be 
maintained  in  the  reports/letters  file.  All  matters 
concerning  disputes,  errors  and  omissions,  design  defici- 
ences,  etc.  require  correspondence.  A  word  processor  can  be 
used  to  produce  these  documents.  Copies  of  any  documents 
should  be  placed  in  the  contract  file. 

J.   FIHA1  PAYMENT  (III. 10) 

The  final  payment  request  is  handled  in  the  same  manner 
as  the  progress  payments  except  the  contract  must  be  checked 
to  ensure  that  all  requirements  have  been  met.  The  same 
spreadsheet  database  is  used  in  this  process. 

K.   CONTRACTOR  RELEASE  (III. 11) 

The  tracking  system  is  used  to  ensure  that  all  required 
submissions  have  been  made.  The  lead  engineer  mast  also 
provide  his  approval.  The  document  form  is  maintained  in  the 
reports/letters  file  for  the  contractor  release.  A  copy  o 
the  release  form  is  placed  in  the  contract  file. 
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I.   A-E  IEBFOEMANCE  REPORT  DD  1413  (III. 12) 

The  form  report  is  contained  in  the  reports/letters 
file.  The  CS  and  lead  engineer  complete  the  form  and  the 
completed  form  is  add€d  to  the  Contractor  Information  System 
file.  The  report  is  also  distributed  to  the  required  distri- 
bution. The  required  distribution  listing  can  be  maintained 
with  the  form. 
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II.  END-USER  INTERFACE 

A.   END-OSER  PERCEPTIONS 

The  A-E  contract  MIS  described  in  the  previous  three 
chapters  is  intended  to  aid  the  contracting  officer  acd  the 
CS  in  managing  and  administering  the  A-E  contracting 
process-  The  end-users  of  the  system,  the  contracting 
officer  and  his  staff,  perceive  automated  systems  and  the 
use  of  computers  in  different  frames  of  reference.  The 
contracting  officer,  in  previous  tours  or  through  formal 
schooling,  has  possibly  been  exposed  to  the  use  of  computers 
and  possibly  programming.  The  staff  members  may  or  may  rot 
have  ever  used  a  computer.  The  computer  to  them  may  be 
perceived  to  be  a  threat  to  their  jobs  or  a  new  method  and 
style  cf  work.  Therefore,  there  may  be  resistance  to  the 
change  from  a  fully  manual  process  to  one  in  which  the 
computer  is  an  integral  part. 

Users  judge  and  accept  a  system  on  the  basis  of  their 
personal  experience  with  it.  If  the  system  is  easy  to  learn 
and  use  then  it  is  normally  accepted  and  becomes  a  useful 
tool.  On  the  other  hand,  if  the  system  is  threatening  and 
difficult  to  use  they  will  probably  not  use  it.  This  can 
cause  extreme  problems  if  the  previous  methods  of  performing 
the  work  tasks  are  being  replaced  with  the  automated 
process.  Larson  [Ref.  9:  p-2]  identifies  the  following 
factors  as  affecting  the  end-user's  perception  of  a  computer 
system: 

Time.  How  long  dees  it  take  the  end  user  to  perform  his 
task? 

learning.  How  long  does  it  take  a  novice  to  learr  the 
system? 
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Recall.   How  easy  is  it  for  an  end  user  to  recall  hew  to 

use  the  system  after  he  has  not  used  it  for  some  time? 

Versatility.     Can  the   system   be   used  to   perform   a 

variety  of  tasks  that  the  end  user  faces? 
Errors.    How  many  errors  does  the  end  user  make  and  how 

serious  are  they? 
Help.    Does  the   system  provide  help  when   the  end  user 

has  trouble? 
Adaptability.    Does  the  system  adjust  to  the  end  user's 
level  of   competence  as   he  becomes   more  experienced? 
Does  the  system  tailor  itself  to  the  habits  and  styles 
cf  different  users? 
Concentration,   Hew  many  things  must  an  end  user  keep  in 

mind  while  using  the  system? 
Fatigue.   How  quickly  does  the  user  tire  while  using  the 

system? 
Uniformity.    Are  the  commands   of  this  system  identical 

to  equivalent  commands  of  other  systems? 
Fun.  Does  the  end  user  enjoy  the  system? 
Chapters  6-8  described  various  automated  tools  which  can  be 
used  in  the  three  phases  of  the  A-E  contracting  process.  The 
design  and  development  of  these  tools  could  be  excellent  but 
if  the  end-user  has  difficulty  in  understanding  or  using  the 
tools  they  are  useless.  End-user  interfaces  must  be  designed 
into  the  system  to  ensure  the  above  factors  are  satisfied. 
Failure  to  satisfy  them  can  result  in  the  users  not  using 
the  system  or  not  gaining  the  full  benefits  from  the  use  of 
the  system. 

E.   SCREEN  DESIGNS 

The  A-E  contracting  MIS  must  be  designed  to  permit  the  user 
to  perform  the  contracting  process  tasks  in  a  smooth  manner. 
A  major   element  in  achieving  this   is  the  structure   of  the 
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system  and  how  it  is  configured.  This  will  be  described  in 
the  following  chapter.  The  second  element  to  this  achieve- 
ment is  the  design  of  the  methods  by  which  the  user  is 
"guided"  through  the  system.  These  methods  include  the  use 
of  menus,  prompts,  information  presentation,  data  presenta- 
tion, text  presentation,  messages  and  replies,  and  help 
facilities  [Sef.  10:  pp. 19-2 1,34,36-37 ]• 

1 .   Menus 

Menus  present  the  user  with  a  number  of  choices,  the  user 
keys  in  his  choice  and  the  system  moves  on.  Menus  can 
present  any  number  of  choices,  however  as  the  number 
increases  so  does  the  confusion  of  the  user.  Menu  options 
should  be  limited  tc  as  small  a  number  as  possible.  As  an 
example   consider   the   main  menu   used   in   the   Ccntractor 


...... 

MAIN  MENO 

A) 

Add  a  record 

D) 

Delete  a  record 

E) 

Exit  (  work  completed  ) 

H) 

Help 

P) 

Print  a  report 

Q) 

make  a  Query 

0) 

Update  a  record 

V) 

View  a  record 

Choose  an  op 

tion:  _ 

Figure  9.1    Contractor  Information  System  Main  Menu. 

Information  System,  Figure  9.1.   This  menu  offers  the  user  a 
selection  of  all  the  possible  options  and  features  available 
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under  the  CIS  application  module.  The  user  knows  by  the 
names  used  for  the  options  what  can  be  performed  by  using 
this  module.  The  options  are  listed  in  alphabetical  order 
where  the  option  selection  keys,  (A,  D,  E,  H,  P,  Q,  U,  and 
V) ,  correspond  to  the  key  word  of  the  option.  If  more  than 
nine  options  are  necessary,  it  is  better  to  divide  the  menu 
into  two  separate  menus,  chaining  them  together. 

2 .   Prompts 

Prompts  are  text  on  the  screen  identifying  the  type 
of  information  that  the  system  desires  the  user  to  enter.  In 
simple  terms,  they  are  just  questions  and  answers.  At  the 
conclusion  of  entering  a  new  record  into  the  CIS  database 
the  user  is  ask,  "DO  YOU  WANT  TO  INPOT  ANOTHER  RECORD?  (Y  OR 
N) " .  The  system  waits  for  a  response  from  the  user  before 
any  other  action  takes  place. 

Prompts  can  also  take  the  form  of  screen  overlays 
which  show  the  format  for  the  entry  of  data.  Figure  9.2  is 
the  data  entry  format  used  to  add  records  to  the  CIS  data- 
base. In  this  approach,  the  cursor  appears  at  the  first 
entry  point,  Contractor  Number,  for  the  entry  of  the  first 
data.  Only  four  digits  are  permitted  for  the  contractor 
number.  This  limitation  is  shown  by  the  number  of  flank 
spaces  in  the  prompt.  Rather  than  using  blanks,  reverse 
video  highlights  the  entry  areas  and  limitation  on  the  allo- 
wable data  entry  field  length.  Reverse  video  is  not  provided 
on  all  terminals.  After  the  user  has  entered  the  first  data, 
the  cursor  jumps  to  the  next  data  entry  area,  Phone.  The 
user  can  move  back  to  a  previous  data  entry  area  to  change 
data  if  required.  Methods  for  this  movement  between  data 
areas  is  dependent  upon  the  hardware  utilized.  The  cursor 
continues  to  move  to  the  next  data  entry  area  until  all  the 
data  has  been  entered  for  this  screen.  The  CIS  requires  two 
screens   to   input   all   the   contractor   information.    The 
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completion  of  the  last  data  item,  Fee  for  project  3,  will 
automatically  call  the  next  screen  up  for  the  user  to 
complete.  If  any  data  item  is  not  known  or  not  applicable, 
the  entry  area  can  be  skipped  by  pressing  the  return  key. 

The  entry  screens  should  call  for  the  information  as 
it  appears  on  the  source  documents.  This  will  permit  the 
user  to  go  through  the  source  document  smoothly  rather  than 
jumping  randomly  over  it.  Crowding  too  much  on  one  screen 
makes  the  entry  process  difficult.  There  should  be  space 
between  each  data  entry  area. 


CONTRACTOR  DATA  FILE 

Contractor  Number  - Phone  -  ( )- -__ 

Contractor  Name  -  

Street  or  P.O.Box  -  

City  - 


State  -    Zip  - 


Project  1  - 

Fee  - ' 

Project"  7~ ~ 

Fee  - 

Project"  3  -  

Fee  - 


PROJECT  HISTORY 


Figure  9.2   Data  Entry  Screen  for  CIS 


3-   Information  Presentation 

Information  presented  to  the  user  should  be  in  a 
usable  form.  For  example,  the  tracking  systems  for  all  the 
contracting  phases  require  the  entry  of  several  dates  by  the 
user.  The  dates  should  always  be  asked  for  by  the  system  in 
a  form   that  is  normally  used   by  the  user   (i.e.   DD/Mtf/YY, 
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MM/DD/YY  or  even  May  18,  1984).  These  forms  are  common  to 
everyday  use.  While  these  forms  are  easiest  for  the  user, 
the  Julian  date  system  is  more  practical  for  use  in  computa- 
tions undertaken  by  the  computer.  The  input  from  the  user 
in  one  of  the  above  forms  can  be  easily  converted  to  a 
Julian  date  by  the  computer.  Likewise  the  output  or  presen- 
tation of  the  information  to  the  user  should  be  in  a 
normally  acceptable  form.  The  computer  should  convert  any 
internal  data  format  to  a  readable  format  for  the  user.  The 
user  should  never  have  to  rely  on  a  coding  scheme  to 
decipher  information  presented  by  the  computer  for  his  use. 

4  •   £§£§  Presentation 

Data  presentation  concerns  the  display  of  non-native 
language  irformation  en  the  screen.  Most  of  the  information 
presented  in  the  proposed  A-E  MIS  is  in  a  readable  form. 
There  could  be  applications  which  would  list  cost  data  along 
with  cost  category  codes  or  contractor  numbers.  The  data 
should  be  identified  by  titles  or  headings  of  some  sort. 
Displays  such  as  47528052347654,  where  4752  is  the 
contractor  number  and  (805) -234-7654  is  the  contractors 
phone  number,  make  no  sense  to  the  normal  user.  An  example 
of  acceptable  data  presentation  is  the  Contractor  Discipline 
Profile  screen  shown  in  Figure  9.3.  The  main  body  of  the 
screen  displays  the  discipline  codes  and  the  number  of 
personnel  are  in  the  discipline  category.  The  discipline 
codes  are  numeric  as  are  the  count  of  personnel  in  the 
categories.  Each  code  and  count  number  are  separated  and  the 

definition  of   the  code  is  listed   (i.e.   10  25   Civil  Eng 

indicating  there  are  25  persons  in  discipline  category  10 
which  is  Civil  Engineers). 
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CONTRACTOR  DISCIPLINE  PROFILE 


Contractor  Number  - 
Contractor  Name  - 


Discipline  Code  -  Number  of  Personnel 

0  1   _24  Administrative  02   _20  Electrical  Eng 

03  '  Oceano grahers  04   "10  Architect 

05  Estimators         06  Urban  Planners 

07  '  Chemical  Eng  08  Geologists 

09  '   3  Sanitary  Eng  10   _75  Civil  Eng 

11  _2 Hydrologists  12  Soils  Eng 

13 Construct  Insptr  14    "8  Inter.  Design 

15  '  Spec  Writer  16  _Z"T2  Draftsman 

17   _U  Landscape  Arch  18  Structural  Eng 

19  Ecologists         20 "9  Mechanical  Eng 

2  1  _"j"T"^  Surveyors  22 Economists 

23  Mining  Eng  24  Transport  Eng 

25 General 

— >  DC  YOU  WANT  TO  INPUT  ANOTHER  RECORD?  (  Y  or  N  ) 


Figure  9.3    CIS  Contractor  Discipline  Profile  Screen. 

5 •   lex t  Presentation 

It  is  often  necessary*  to  give  instructions  or 
present  information  in  the  form  of  text.  For  reading  ease, 
the  text  should  be  in  upper  and  lower  case.  The  text  should 
be  presented  in  short  sentences,  allowing  enough  space 
between  paragraphs  so  as  not  to  crowd  the  screen.  If  neces- 
sary, use  more  than  one  screen  to  display  the  information 
rather  than  crowd  toe  much  on  one  screen.  Figure  9.4  illus- 
trates these  concepts.  The  instructions  appear  in  the 
module  used  to  view  contractor  data.  The  instructions  are 
brief  and  to  the  point.  Since  there  is  more  information  than 
can  be  presented  on  one  screen,  two  screens  are  used.  The 
user  can  scroll  to  the  second  screen  by  simply  hitting  any 
key.  The  browsing  instructions  given  on  the  second  screen 
also  appear  on  the  data  screens  in  an  abbreviated  form. 
Simplicity  and  understandability  are  the  key  elements  to  be 
followed. 


82 


**SCREEN  1** 

To  view  a  specific  contractor's  data  record  you  need 
to  know  the  contractor  number. 

If  a  specific  number  is  not  used  you  will  begin  with 
the  first  record.  The  records  are  arranged  in 
alphabetical  order  by  contractor  name. 

You  can  also  just  browse  thru  the  records. 


PRESS  ANY  KEY  TO  CONTINUE 

**SCREEN  2** 


The  following  options  are  available  in  browse: 

B) ack--Takes  you  to  the  previous  record. 
F) orward — Takes  you  to  the  next  record. 
P) rof ile — Displays  the  Discipline  Profile. 

of  the  contractor. 
N) umber — Permits  you  to  locate  a  contractor 

by  the  contractor  number. 
Q) uit — Returns  you  to  the  main  menu. 

Do  you  need  to  see  a  listing  of  the  contractor  numbers? 


Figure  9.4    Text  Presentation  in  the  CIS  Module. 

6 .   Messages  and  Replies 

Communications  that  emanate  from  the  computer  to  the 
user  form  a  direct  psychological  link  between  the  user  and 
the  computer.  These  communications  give  the  computer  some 
human-like  qualities  that  tend  to  be  perceived  to  threaten 
the  user.  Like  conversing  with  an  individual,  the  computer 
should  never  produce  a  blank  screen.  This  lack  of  feedback 
often  gives  the  user  a  feeling  of  being  lost.  If  a  process 
is  being  carried  out  which  requires  more  than  3  seconds,  it 
is  best  to  provide  a  message  to  the  user  that  a  process  is 
taking  place.  In  the  CIS  module,  the  initialization  of 
memory  variables  requires  approximately   10  seconds.   During 


this  time,  the  user  is  presented  with  a  sign-on  screen 
display  as  shown  in  Figure  9.5.  The  display  of  the  screen 
does  not  make  the  initialization  process  go  any  faster,  rut 
the  user  is  told  of. the  time  reguirement  and  exactly  what  is 
going  on. 


NAVFACENGCOM 
Contractor  Information  System 


A  Micic-Processor  Application 
of 

FACSO's  CIS 


Developed  by: 

TOM  ETHFRIDGE 

SPRING  QUARTER  1984 
NAVAI  POSTGRADUATE  SCHOOL 


Wait  10  seconds  for  system  initialization  to  complete. 
>  Press  any  key  to  continue  < 


Figure  9.5   CIS  Sign-on  Screen  Display. 

The  most  valuable  messages  in  terms  of  system 
control  and  protection  are  error  messages.  They  inform  the 
user  of  mistakes  or  the  failure  to  comply  with  system 
imposed  constraints  such  as  data  formats.  Error  messages 
should  be  concise  and  yet  provide  enough  information  for  the 
user  to  recover  from  an  error.  Verbosity  and  error  messages 
do  not  go  together.  Ehen  possible,  the  error  message  should 
permit  an  escape  for  the  user.  Figure  9.6  is  an  example  of 
an  error  message  used  in  the  delete  module  of  the  CIS.  This 
message  appears  when  the  user  reguests  to  delete  a 
contractor  record  that  does  not  exist  in  the  file.   The  user 
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is  told  that  the  contractor  record  does  not  exist.  Then  the 
user  is  given  an  opticn  or  an  escape.  The  user  is  not  left 
wondering  what  should  be  done. 


That  contractor  number  is  not  in  the  file. 

Do  you  want  to: 

1)  Try  again  or, 

2)  Return  to  main  menu. 


Figure  9.6    Sample  Error  Message. 


"7-   H§i£  Facilities 

On-line  help  facilities  are  an  advantage  if  they  can 
provide  information  for  the  user  in  a  capsulated  form.  If 
extensive  helps  are  required  they  should  be  provided  in  the 
user's  manual.  Concise  helps  or  memory  aids  can  save  the 
user  the  effort  of  having  to  continuously  go  to  the  refer- 
ence material.  For  a  large  diverse  system  it  is  best  to 
design  the  help  facilities  such  that  they  reside  in  the 
modules  in  which  they  are  needed  rather  than  in  cne  large 
separate  module.  A  menu  of  help  information  should  be 
presented  where  the  user  can  choose  the  desired  help. 

C.   INTERFACE  TRADE-CPFS 

All  the  interfaces  described  in  the  above  paragraphs  are 
included  in  the  system  to  improve  the  "friendliness"  of  the 
system.   These  aids   to  system  use  require   storage  space  in 
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memory  as  do  the  application  modules  and  data.  There  has  to 
be  a  littit  to  the  aids  provided  in  order  to  balance  the 
storage  requirements.  Consideration  must  be  given  tc  the 
number  of  help  facilities  and  the  amount  of  information 
contained  in  each.  The  other  trade-off  to  be  considered  is 
the  time  response  cf  the  system  when  a  large  number  of 
interface  aids  are  provided.  These  problems  of  storage  are 
being  overcome  by  the  current  advances  in  storage 
technologies. 
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X.  SYSTEM  INTEGRATION 

Chapters  6  through  8  presented  a  proposal  for  an  auto- 
mated approach  to  the  management  of  the  A-E  contracting 
process.  The  last  chapter  stressed  the  importance  of  the 
interface  between  the  user  and  the  automated  system.  This 
chapter  will  present  the  system  components  in  a  MIS  frame- 
work and  explore  the  hardware  and  software  aspects  to  be 
considered  for  i  npleirentation  of  the  MIS. 

A.   OVERVIEW 

In  Chapter  5,  a  MIS  framework  was  described  as  an  inte- 
grated system  for  providing  planning,  operation,  and  control 
of  a  management  function.  The  proposed  A-E  automated 
tracking  and  management  system  presented  earlier  fits  best 
into  this  framework  as  shown  in  Figure  10.1.  The  functions 
of  the  databases,  reports/letter  file,  contract  files,  and 
application  programs  are  integrated  to  form  the  A-E  MIS. 
The  user  accesses  the  MIS  through  the  use  of  a  workstation 
equipped  with  a  keyboard  for  data  entry,  a  CRT  for  viewing 
system  responses  and  dialogue  screens,  and  a  printer 
utilized  to  produce  hardcopy  printouts  of  reports,  letters, 
and  schedules.  The  user  interacts  with  the  MIS  at  the 
highest  level  through  the  supervisory  program.  This 
program,  through  menus  and  user  friendly  prompts,  permits 
the  user  to  select  cne  of  the  functions  or  applications1 
available  for  use.  After  a  selecting  of  one  of  the  func- 
tions, control  of  the  MIS  shifts  to  that  function,  meaning 
that  the  user   interacts  directly  with  the   function.    This 


*A  complete  listing  of  the  application  programs, 
reports/letters  file,  contract  files,  and  databases  proposed 
for  the  A-E  MIS  can  be  found  in  Appendix  B. 
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DATABASES 


CONTRACT 
FILES 


PROGRAM- 
MODULES 


T 


APPLICATIONS 


TERMINAL 


SUPERVISOR 
PROGRAM 


'OUTPUT 


INPUT 


Figure  10. 1    A-E  Contracting  MIS. 

level  cf  control  is  below  that  of  the  supervisory  program  in 
a  manner  that  when  the  user  completes  the  use  of  the 
selected  function,  control  always  reverts  back  to  the  super- 
visory program.  Application  programs  normally  consist  of 
several  modules  much  like  the  CIS  application  program  listed 
in  Appendix  A.  During  execution  of  an  application,  control 
may  be  passed  to  any  cf  the  modules.  But,  just  as  with  the 
supervisory  program,  when  the  modules'  process  is  complete, 
control  returns  to  the  main  module  of  the  application. 

Once  the  user  has  access  to  a  particular  application, 
other  functions  of  the  MIS  come  into  play.  The  application 
program  may  call  or  access  one  of  the  databases,  a  form 
report/letter  from  the  reports/letters  file,  a  contract  file 
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or  any  combination  of  these  functions.  As  mentioned  above, 
when  the  user  is  finished  with  the  application  or  function, 
control  returns  back  to  the  supervisory  program  where  the 
user  can  activate  another  application  or  simply  leave  the 
system. 

B.  DATA  DICTIONARY 

A  subsystem  not  shown  in  Figure  10. 1  but  which  plays  an 
important  role  in  the  useability  of  the  MIS  is  the  data 
dictionary.  The  data  dictionary  is  documentation  of  the  data 
items  included  in  the  databases  together  with  their  rela- 
tionships with  other  data  and  programs  or  routines  that  use 
them.  The  major  purpose  of  the  data  dictionary  is  to  aid  in 
the  consistency  of  the  MIS  data.  It  normally  contains  data 
field  definitions  (how  many  spaces  are  permitted  for  a  data 
element),  data  definitions  (what  is  and  is  not  included  in 
the  data  element) ,  and  comment  information  to  explain  any 
ambiguities  in  the  data  elements.  Data  dictionaries  can 
contain  explanations  cf  any  restrictions  on  data,  enforce- 
ment measures  utilized  by  the  database  (error  checking  for 
data  entry) ,  or  modules  for  monitoring  the  usage  of  data. 
The  data  dictionary  can  be  either  in  hardcopy  form  such  as 
[Bef.  6],  or  be  available  on-line.  In  most  cases,  it  is  best 
to  have  hardcopy  documentation  of  the  data  dictionary  with 
an  abbreviated  form  available  on-line  since  microcomputer 
systems  normally  have  limited  storage  capability.  This 
constraint  will  vary  from  system  to  system  and  will  become 
less  and  less  a  constraint  as  storage  technology  advances. 

C.  IMPLEMENTATION  OE  THE  MIS 

The  concepts  proposed  in  the  previous  chapters  have  been 
based  on  the  idea  that  the  field  activities  need  the  ability 
to   manage   and  control   their   functional   responsibilities 
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through  the  use  of  existing  computer  technologies.  The  hard- 
ware and  software  reguired  to  implement  the  proposed  A-2 
MIS,  as  well  as  any  ether  small  activity  management  systems, 
currently  exists  on  the  commercial  market.  The  A-E  MIS  is 
suitable  for  operation  on  most  business  microcomputers  being 
used  today.  The  microcomputer  has  several  advantages  over  a 
larger  system  for  this  application,  of  which  the  first  is 
cost.  Mcst  micro-based  systems  can  be  purchased  for  less 
than  $5,000  and  many  less  than  $3,000.  The  second  is  that 
technologically  better  computers  are  produced  at  a  lower 
cost  while  at  the  same  time  the  amount  of  storage  capacity 
built  in  them  drastically  increases.  The  standard  business 
micro-computer  in  1983  had  192K  to  256K  of  internal  memory 
with  normally  dual  300K  to  400K  floppy  disk  drives  providing 
the  user  with  600K  tc  800K  of  easily  accessed  memory.  In 
1984,  micro-computers  are  equipped  with  the  same  amount  of 
internal  memory  but  with  a  greater  than  tenfold  increase  in 
storage  memory  of  10  Megabytes.  In  1985,  micro-  computers 
are  projected  to  provide  512K  of  internal  memory  and 
possibly  205  Megabytes  of  storage  memory.  In  the  next  few 
years,  it  is  projected  that  read  only  laser  disk  storage 
providing  up  to  4  gigabytes  of  read  only  storage  will  be 
available.  All  the  storage  memory  devices  will  be  located 
within  the  actual  micro-computer  frame.  Existing  microcom- 
puter can  be  upgraded  to  take  advantage  of  the  advances  in 
storage  memory.  A  third  advantage  of  the  micro-  computer  is 
its  ability  to  be  easily  adapted  to  the  organizational 
management  style.  The  size  and  cost  of  the  micro-  computer 
permits  management  to  place  the  computing  power  on  the  desk 
of  those  who  need  it. 

Commercial  software  products  are  available  which  provide 
the  facilities  necessary  to  implement  the  proposed  A-E  MIS. 
These  application  products  can  also  be  used  by  the  aggres- 
sive manager  to  develop  personal  management  tools  as  well  as 
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expand  on  those  proposed  herein.  The  ease  of  use  and  the 
high  level  orientation  of  these  products  make  the  need  for 
systems  programmers  obsolete  for  the  development  of  siirpier 
applications. 

The  CIS  programs  listed  in  Appendix  A  were  developed  on 
a  Zenith  Z-1002  through  the  use  of  two  compatible  software 
products,  dBASE  II3  and  'WordStar'.4  dBASE  II  is  a  database 
management  tool  that  allows  easy  manipulation  of  snail  and 
medium  sized  databases  using  English-like  commands.  WordStar 
is  a  word  processing  program.  These  two  application  pack- 
ages could  be  used  to  develop  the  entire  A-E  MIS.  Other 
software  packages  could  be  used  but  these  two  are  completely 
compatible  taking  a  major  effort  of  internal  system  inter- 
facing out  of  the  design  effort.  The  systems  should  also 
work  en  any  IBM  compatible  and  a  large  variety  of  CP/M*5 
systems. 


2Zenith  Z-100  is  a  registered  trademark  of   Zenith  Data 
Systems. 

3dEASE  II  is  a  registered  trademark  of  Ashton-Tate. 

♦WordStar   is    a  registered    trademark  of    MicroPro 
International. 

5CP/M  is  a  registered  trademark  of  Digital  Research. 
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XI.  CONCIDSIONS  AND  RECOMMENDATIONS 

A.   CONCLUSIONS 

For  NAVFAC  to  effectively  carry  out  their  mission  objec- 
tives, enormous  amounts  of  data  are  required  to  be 
collected,  organized  into  logical  informational  forms,  and 
analyzed.  Well  developed  information  management  systems  are 
used  to  nake  this  possible.  The  systems  utilize!  are 
reviewed  annually  to  ensure  that  they  adequately  support  the 
mission.  Systems  enhancements  are  developed  and  installed  to 
farther  the  inclusion  of  improved  technological  advances. 

The  irajority  of  the  computing  power  used  by  the  NAVFAC 
Naval  Facilities  System  is  centrally  located  in  Port 
Hueneme,  Ca.  at  FACSO.  The  data  from  field  activities  is 
collected  at  decentralized  sites  (EFDs)  and  forwarded  to  the 
central  site  (FACSO) .  The  reports  utilized  for  management  of 
NAVFAC  functions  are  distributed  in  hardcopy  form  to  the 
field  activities.  The  major  decisions  concerning  planning 
and  requirements  definition  for  the  Naval  Facilities  System 
Plan  is  centralized  at  NAVFAC  Headquarters.  The  execution 
and  implementation  of  the  plans  is  centralized  at  FACSO. 

The  current  objective  of  the  Naval  Facilities  System  is 
to  depart  from  the  wholly  centralized  approach  of  data 
processing  and  to  decentralize  some  system  functions 
[Ref.  1:  p. 5-1]-  The  initial  decentralization  is  focused  at 
the  EFDs,  Public  Works  Centers  and  larger  Public  Works 
Departments.  This  is  a  decentralization  of  hardware  and 
software  but  not  systems  development.  Development  of  major 
systems  is  to  remain  at  FACSO  and  planning  for  NAVFAC-wide 
systems  will  remain  at  NAVFAC  Headquarters.  The 
decentralized  sites   will  be  able   to  develop   local  systems 
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and  amplications  which  can  effectively  improve  procedures 
and  management.  This  decentralization  is  slowly  evolving 
down  to  the  field  activity  level.  Some  applications  have 
leen  developed  to  support  field  activities,  however  most  are 
presently  geared  toward  collecting  and  submitting  data  in 
support  of  the  major  NAVFAC  data  processing  systems. 

Several  management  processes  exercised  at  the  field 
activity  level  could  be  improved  and  modernized  by  the 
development  of  automated  data  processing  applications.  The 
A-E  contracting  management  process  is  just  one  of  these 
processes.  Develop  cf  applications  as  described  in  Chapters 
6-8  is  possible  as  evidenced  by  the  development  of  the 
Contractor  Informaticn  System  shown  in  Appendix  A. 

Current  micro-computer  technology  will  support  the  auto- 
mation requirements  cf  field  activities  since  advances  have 
greatly  increased  the  secondary  storage  capacity  cf  these 
machines.  Many  application  building  tools  such  as  word 
processing,  database,  and  electronic  spreadsheets  software 
are  available  for  development  of  management  systems.  These 
tools  are  at  the  level  that  the  aggressive  manager  can 
develop  local  applications  to  improve  his  own  management 
techniques  and  performance.*  Micro-computers  can  easily  be 
adapted  for  transmission  of  data  to  other  computers  as  well 
as  integrated  into  local  area  networks  where  several  micro- 
computer can  share  applications  and  computing  power.  The 
cost/benefit/performance  considerations  of  micro-computers 
make  them  excellent  tcols. 

E.   RECOMMENDATIONS 

The  main  theme  cf  the  recommendations  to  be  made  is  to 
take  a  unified  planning  approach  in  evaluating  data 
processing  for  field  activities.  The  recommendations  are  as 
follows: 
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1.  A  centralized  abroach  should  be  taken  to  identify  the 
key  needs  of  the  field  activities  in  the  area  of  data 
processing.  Orly  those  functions  which  are  of  benefit 
to  the  majority  of  the  activities  should  be  pursued. 
Possibly  subgroups  can  be  identified  for  secondary 
consideration  by  those  activities  affected. 

2.  A  centralized  evaluation  and  selection  of  available 
software  (word  processors,  database  managers,  and 
electronic  spreadsheets)  should  be  made  to  reduce  the 
cause  of  inconsistent  applications  development.  The 
number  of  permitted  software  products  should  be  kept  to 
a  minimum  while  at  the  same  time  permit  enough 
diversification  to  avoid  dependence  on  one  vender  or 
system. 

3.  Similar  to  2  above,  a  centralized  evaluation  should  be 
made  of  available  micro-computers.  Limiting  the 
selection  to  not  only  operating  systems  [Ref.  11],  hut 
also  to  vendors  would  again  aid  in  reducing  fcue 
proliferation  of  hardware. 

4.  Establish  field  activity  user  groups  where 
communications  can  begin  for  the  purpose  of  sharing 
ideas,  problem  solutions,  and  applications.  Due  to  the 
large  geographic  dispersion  of  the  activities,  central 
centers  for   information  exchange  should   be  identified 

(newsletters,    regional  periodic   meetings,    software 
exchanges) . 

5.  An  aggressive  approach  toward  the  integration  of  the 
field  activity  systems  into  the  NFS  will  take  advantage 
of  current  technology.  The  increased  sophistication  of 
sirall  computer  systems  and  the  advances  of 
communications  software  bring  these  two  functions 
closer  together. 

6.  Incorporate  a  total  system  approach  to  systems 
development  to   merge  the   areas  of   office  automation, 
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data  processing,  and  communications  technology.  This 
should  lead  to  future  developments  iear.ing  toward 
Information  Resource  Management. 

7.  Institute  learning  centers  for  the  purpose  of 
exploiting  the  benefits  cf  £.j.cro-computer:-j  at  the  •  ieid 
activity  level.  These  center^  could  be  located  at  Z?7)^t 
PWCs,  or  at  the  Civil  Engino--r  Corps  Officers  Schcc^  in 
Fort  Hueneme,  Ca. 

8.  Include  in  the  Favy  Facilities  System  Plan,  Eef.  1, 
long  range  plans  for  the  development  of  data  processing 
systems  for  field  activities. 

9.  Design  and  implement  the  A-E  contract  management  system 
similar  to  that  described  in  this  thesis.  The  system 
should  be  field  tested,  refined  and  distributed  to 
other  field  activities  for  use. 
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APPENDIX  A 
SAMPLE  APPLICATION 

CONTRACTOR  INFORMATION  SYSTEM 
-  A  dBASE  II  PROGRAM  - 

The   dEASE  II  ccirmand  language  has  been  used  to  implement   a 

contractor   information  system    used   by  Naval    Facilities 

Engineering   Command.   The  system  has  been  designed   under   the 
following  assumptions: 

a)  Users  of  the  systems  are  inexperienced  in   computer 
usage. 

b)  The  system  should  permit  facilities  tc  add,   delete 
and  browse  thru  the  data.  It  should  also  permit  any 
persons  knowledgeable  with  dBASE  II  to  use  the 
query  language   on  .the   database.   (  This  is  made 
only  under  the   premise  that   the  system  will  be 
used  by  a  small  group  (  3-4  persons) .  It  should 
also  be  pointed  that  by  having  access  to  the 
database  that  a  person  can  change  the  database  by 
deleting  records  or  modifying  existing  data. 

c)  The  system  is  used  by  a  small  group  of  people. 

d)  The   database  should  as  much  as  possible  te 
designed  to  match  the  database  structure  of  the 
existing  NAVFAC  database.  This  will  make  future 
interfacing  with  easier. 

Two  files  are  maintained.  The  contractor  data  file  (cdata) 
and  the  contractor  discipline  file  (cdis).  The  cdata. dbf  contains 
basic  demographic  information  plus  a  short  history  of  the 
contractor's  work  for  the  USN.  The  cdis. dbf  contains  a  breakdown 
of  the  composition  of  the  contractor's  engineering  workforce 
This  data  is  taken  from  the  SF  254  and  SF  255.  These  forms  are 
the  D.S.  Governments  contractor  resume  forms.  The  information  is 
maintained  for  future  Invitation  For  Bid  mailing  lists  and  also 
for  a  reference  for  the  Public  Works  Officer  to  consult  when  he 
needs  a  rapid  response  design  to  solve  an  emergent  problem. 

The  file  structures  for  the  two  dbfs  are  given  below.  A 
brief  data  dictionary  is  also  given  to  aid  in  defining  the  fields 
and  data  elements. 
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STRUCTURE  FOR  FILE: 

CDATA. DBF 

NUMBER  OF  RECORDS: 

C0010 

DATE  CF  IAST  UPDATE: 

06/12/84 

PRIMARY  USE  DATABASE 

FID        NAME 

TvpE 

WIDTH 

001      CNUM1 

C 

004 

002      CNAHE1 

C 

036 

003      CNAME2 

C 

036 

004      STPOB 

C 

040 

005      CITY 

c 

021 

006      STATE 

c 

002 

007      ZIP 

c 

005 

008      EHONE 

c 

014 

009      FROJ1 

c 

050 
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010      FEE1 

C 

006 

011      FROJ2 

C 

050 

012      FEE2 

c 

006 

013      FROJ3 

c 

050 

014      FEE3 

c 

006 

015      DELETED 

c 

007 

**  TOTAL  ** 

00334 

Field 
1 

CNUM1 

2 

CNAME1 

3 

CNAME2 

4 

STPOP 

5 

CITY 

6 

STATE 

7 

ZIP 

8 

IHCNE 

-+-+-+-+-+-+-+-   CDATA  Data  Dictionary   -+-♦-+-+-+-+-♦- 

Contractor  number  assigned  automatically  by  the 

system.  4  alphanumeric  spaces  are  permitted. 

Contractor  name,  first  line.  36  alpha  characters 

are  permitted. 

Contractor  name,  second  line.  36  alpha  characters 

are  permitted. 

Street  address  or  the  post  office  box.  40 

alphanumeric  characters  permitted. 

City  cf  the  address.  21  alpha  characters  are 

permitted. 

State  of  the  address,  2  letter  abnreviations.  2 

alpha  charcaters  are  permitted. 

Zip  cede  associated  with  the  address.  5 

alphanumeric  characters  are  permitted. 

Telephone  number  of  the  contractor  including  the 

area  code.  14  alphanumeric  characters  are 

permitted. 

9  FROJ1    Brief  description  of  the  latest  project  completed 

by  the  contractor  for  the  government.  50  alpha 
characters  are  permitted. 

10  FEE1     The  fee  in  thousands  of  dollars  paid  to  the 

contractor  for  the  projected  completed  above. 
6  alphanumeric  characters  are  permitted. 

11  PROJ2    Same  as  PROJ1  except  for  second  project. 

12  FEE2     Same  as  FEE1  except  represents  PKOJ2. 

13  PROJ3    See  above. 

14  FEE3     See  above. 

15  DELETED  Field  used  to  indicate  that  a  record  has  been 

identified  for  deletion.  7  alpha  characters  are 
permitted. 

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-♦-+-+-+-+-+-+-+-+-+-+-+-+-+- 

The  cdata  file  is  indexed  to  the  file  NAMES. MDX  by  the  contractor 
names.  A  sample  of  the  data  in  the  cdata. dbf: 

0000  1   1234  WESCOTT  BROTHERS  DESIGN  AND  ESTIMATE 

00002  2345  JOHNSON  AND  JOHNSON  ASSOC.  INC. 

00003  3456  ABC  ENGINEERING 

00004  4567  FIRST  RATE  GUYS  WITH  A  SLIDE  RULE 

00005  5678  ONE  MAN  ENGINNERING  COMPANY 

00006  6787  KEPLER  FRANK  AND  WESPEPPER 

00007  8765  ZEDE  PLUMEING  AND  HEATING 

00008  9065  BROWN  AND  ROOT 

00009  7303  DIEBOLD  PIPE  AND  S1EEL  ENGINEERS 

00010  4532  WERE  YOU  IHERE 

The   CDIS    dbf: 

STRUCTURE    FOR    FILE:       CDIS. DBF 

NUMBER    OF    RECORDS:  C0010 

DATE    CF    LAST    UPDATE:    06/12/84 

SECONDARY    USE    DATABASE 

FLD  NAME  TYPE    WIDTH         DEC 

001  CNUM2  C  004 

002  NAD  C  004 

003  NEE  C  004 
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-+-♦-+-+-+-+-+-  CDIS  Data  Dictionary 


004 

NOG 

005 

NA 

006 

NEST 

007 

NDP 

008 

NCHE 

009 

NGE 

010 

NSNE 

011 

NCE 

012 

NHY 

013 

NSOE 

014 

NCI 

015 

NID 

016 

NSPW 

017 

NDMN 

018 

NIA 

019 

NSTE 

020 

NECO 

021 

NME 

022 

NSUR 

023 

NECN 

024 

KMNE 

025 

NTRE 

026 

NGE 

027 

TOTEMP 

**  TCTAI  ** 

.+-♦-+-+- 

Field 

1 

CNUM2 

2 

NAD 

3 

NEE 

4 

NOG 

5 

NA 

6 

NEST 

7 

NUP 

8 

NCHE 

9 

NGE 

10 

NSNE 

11 

NCE 

12 

NHY 

13 

NSCE 

14 

NCI 

15 

NID 

16 

NSPW 

17 

NDMN 

18 

NIA 

19 

NSTE 

20 

NECO 

C 

004 

C 

004 

c 

004 

C 

004 

C 

004 

C 

004 

C 

004 

C 

004 

C 

004 

C 

004 

C 

004 

c 

004 

c 

004 

c 

004 

c 

004 

c 

004 

c 

004 

c 

004 

c 

004 

c 

004 

c 

004 

c 

004 

c 

004 

c 

006 

0011  1 

-+-+-+-+-+-+-+- 


Contractor  number  assigned  by  the  system. 

This  is  the  same  number  as  CNUM1. 

4  alphanumeric  characters  are  permitted. 

Number  of  administrative  personnel. 

4  alphanumeric  characters  are  permitted. 

Number  of  electrical  engineers. 

4  alphanumeric  characters  are  permitted. 

Number  of  oceanoqraphers. 

4  alphanumeric  characters  are  permitted. 

Number  of  architects. 

4  alphanumeric  characters  are  permitted. 

Number  of  estimators. 

4  alphanumeric  characters  are  permitted. 

Number  of  urban  planners. 

4  alphanumeric  characters  are  permitted. 

Number  of  chemical  engineers. 

4  alphanumeric  characters  are  permitted. 

Number  of  geologists. 

4  alphanumeric  characters  are  permitted. 

Number  of  sanitary  engineers. 

4  alphanumeric  characters  are  permitted. 

Number  of  civil  engineers. 

4  alphanumeric  characters  are  permitted. 

Number  of  hydrologists. 

4  alphanumeric  characters  are  permitted. 

Number  of  soil  engineers. 

4  alphanumeric  characters  are  permitted. 

Number  of  construction  inspectors. 

4  alphanumeric  characters  are  permitted. 

Number  of  interior  designers. 

4  alphanumeric  characters  are  permitted. 

Number  of  spec  writers. 

4  alphanumeric  characters  are  permitted. 

Number  of  draftsmen. 

4  alphanumeric  characters  are  permitted. 

Number  of  landscape  architects. 

4  alphanumeric  characters  are  permitted. 

Number  of  structural  engineers. 

4  alphanumeric  characters  are  permitted. 

Number  of  ecologists. 
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21 

NME 

22 

NSUF. 

23 

NECN 

24 

NMNE 

25 

NTRE 

26 

NGE 

4  alphanumeric  characters  are  permitted. 

Number  of  mechanical  engineers. 

4  alphanumeric  characters  are  permitted. 

Number  of  surveyors. 

4  alphanumeric  characters  are  permitted. 

Number  of  economists. 

4  alphanumeric  characters  are  permitted. 

Number  of  mining  engineers. 

4  alphanumeric  characters  are  permitted. 

Number  of  transportation  engineers. 

4  alphanumeric  characters  are  permitted. 

Number  of  general  engineers. 

4  alphanumeric  characters  are  permitted. 

-+-  +  -♦-+-+-+-  +  -  +  -  ♦-*«•-  +-+-+-+-  +  -  +  -+-  +  -  +  -  +  -+-+-+-+  -+-  +  -+-+-+-+-+-+- 
The  command  files  used  in  the  system  are: 

MAIN. CMD     SIGN-ON. CMD     INIT. CMD 
ADD.CHD      DE1ETE.CMD      QOERY.CMD 
VIEF.CMD 

These  files  are  attached  in  the  order  that  they  appear  here. 

The  format  files  used  are: 

.   GETCDATA.FMT    GETCDIS.FMT  SAYCDATA.FMT 

SAYCDIS.FMT     VCDATA.FMT  VCDIS.FMT 
MAIN. FMT 

These  files  along  with  the  images  they  produce  are  attached. 

Two  memory  files  are  used,  cdata.men  and  cdis.mea.  These 
files  were  not  printed  out.  Their  structure  is  inputted  in  the 
init.cmd  file. 

The  following  pages  contain  the  above  mentioned  files  and 
images. 
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Wain   Command    Module 

****************************************************************** 

*  main.cmd    6/5/84      jt€ 

*  version:  1.0 

*  purpose:  sets  the  lain  selection  screen  and  permits  the  user 

*  to  select  which  option  they  would  like  to  operate 

*  from,  processing  narrative:  the  sign-on  is  displayed 

*  followed  by  the  initialization  of  the  system,  the 

*  main  selection  screen  is  then  presented,  all 

*  terminated  selection  return  the  user  to  the  main  menu. 

*  superordinate  modules:  none 

*  subordinate  modules:  sign-on. cmd,  init.cmd,  main.fmt,  add. cmd, 

*  delete.cmd,  view. cmd 

*  author:  Tom  Etheridge 
*********************************************************  *********. 

♦display  sign-on  message 

DO   sign-cn 

SET    CCNSC1E    OFF 

T3AIT 

SET    CONSOLE    ON 

* 

♦initialize  variables  and  set  the  environment 

DO  init 

* 


♦set  up  the  main  loop 
DO  WHILE  t 


♦set  up  screen 
SET  FORMAT  TO  main 
STORE  "  "  TO  command 
* 

♦display  the  main  menu 

READ 

* 

♦perform    selected    function 
DO    CASE 
* 

CASE   command   =    "3" 

DC    add 

* 

CASE   command   =    "D" 

DC   delete 

* 

CASE  command  =  "E" 

ERASE 

♦prevent  dBASE  11  sign-off  msg 

SET  CONSOLE  OFF 

QUIT 

♦  CASE   command   =    "H" 

♦  DO    help 
* 

♦  CASE   command   =    "P" 

♦  DC   print 
* 

CASE   command   =    "Q" 

DC   guery 

* 

♦  CASE  command   =    "0" 

♦  DC   update 
* 

CASE  command   =    "v" 

DC    view 

* 

ENDCASE 
♦loop    back 

END  DC 
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Sign-on    Command    Module 

****************************************************************** 

*  sign-on. cmd      6/5/8  4  * 

*  version:    1.0  * 

*  purpose:    to   display  the   sign-cn   message  * 

*  processing    narrative:    the   sign-on    msg    is  displayed,    control   is    * 

*  transferred   back   to    main.cmd    when    the  * 

*  user   enters    a   keystroke.  * 

*  superordinate    modules:    main.cmd  * 

*  subordinate   modules:    none  * 

*  author:    Tom   Etheridge  * 
****************************************************************** 

EP.ASE 
7 

?  "  NAVFACENGCOM" 

?  "  Contractor  Information  System" 

7  A 

7 
7 
7 
7 
-> 
7 
?  "  Developed  by:" 

?  "  TOM  ETHERIDGE" 

-> 

?  "  SPRING  QUARTER  1984" 

?  "  NAVAL  POSTGRADUATE  SCHOOL" 

7 

7 

7   it >    fjait    10    seconds   for   system    initialization    to   complete   < " 

7   n >   praSc   any  ^ey    to  continue   < " 
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Initiation  Command  Module 


*  *  *  +  *  *  * 

*  init. 

*  versi 

*  purpo 

*  proce 
* 

* 

*  super 

*  sucor 

*  autho 

3f  ?  ^  T  ^r  *r  *r 

*run  on 
SET  TAL 
SET  INT 
* 

*initia 
*curren 

*  IF  .N 

STOEE 
STOEE 
STOEE 
STOEE 
STOEE 
STOEE 
STCEE 
STOEE 
STOEE 
STOEE 
STCEE 
STOEE 
STOEE 
STOEE 
STOEE 
*crea 
SAVE 
*clea 
RELE5 
*ENDIF 
*IF  . NO 
STOEE 
STCEE 
STOEE 
STOEE 
STOEE 
STOEE 
STOEE 
STCEE 
STOEE 
STCEE 
STORE 
STOEE 
STOEE 
STCEE 
STOEE 
STOEE 
STOEE 
STOEE 
STOEE 
STCEE 
STOEE 
STOEE 
STOEE 
STOEE 
STOEE 
STOEE 
STOEE 


************************************** ************ 

cmd   6/5/84   jte 

on:  1.0 

se:  to  initialize  variables  and  set  the  system  env 

ssing  narrative:  the  environment  is  set  up  followe 

initialing  of  the  variables  used 
add. cmd  module,  creates  cdata.mem 
cdis .mem . 

ordinate  modules:  main. cmd 

dinate  modules:  none 

r:  Tom  Etheridce 
************************************************** 

ce  to  initialize  the  variables  and  set  up  the  envi 

K  OFF 
EliSITY  OFF 

lize  the  variables 

tly  set  to  initialize  variables  during  each  run  of 
01.  FILE  ("cdata.mem") 
"  TO  deleted 


********** 

* 

* 

ironment  * 

d  by  the  * 

in~the"   * 

and     * 

* 

* 

* 

* 

********** 

ronment 


system 


•0000"  TO  mcnum 


TO  mstate 
"  TO  mzip 


"  TO  mcity 
TO  mphone 


"  TO  mcnamel 

"  TO  mcnam€2 

"  TO  mst 


pob 


"  TO  mfeel 
"  TO  mfee2 


"  TO  mfee3 
te  cdata. mem 
TO  cdata 
r  the  memory 
SE  AIL 

T.  FILE ("cdis. mem") 

"0000"  TO  mcnum 

"  TO  mnad 

"  TO  mnee 

"  TO  mnog 

"  TO  mna 

"  TO  mnest 

"  TO  mnur 

"  TO  mnche 

"  TO  mnge 

"  TO  mnsne 

"  TO  mnce 

"  TO  mnhy 

"  TO  mnsce 

"  TO  mnci 

"  TO  mnid 

"  TO  mnspw 

"  TO  mndmn 

"TO  mnla 

"  TO  mnste 

"  TO  mneco 

"  TO  mnme 

"  TO  mnsur 

"  TO  mnecn 

"  TO  mnmne 

"  TO  mntre 

"  TO  mnge 
"  "  TO  answer 


"  TO  mpr 
"  TO  mpr 

"  TO  mpr 
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♦create   cdis.mem 

SAVE    TO    cdis 

♦clear   memory 

RELEASE    ALL 
♦ENDIE 

♦set    up    the   file   environment 
SELECT    PRIMARY 
USE   cdata 
SELECT    SECONDARY 
USE    cdis 
♦return    to   main.cmd 
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Add  A  Contractor  Command  Module 

**************************************************************** 

*  add.cmd      6/6/84      jt€  * 

*  version  1-0  * 

*  purpose:  to  permit  the  addition  of  records  to  the  file       * 

*  processing  narrative:  using  the  getcdata  and  getcdis  formats  * 

*  data  is  collected  from  the  user  and     * 

*  placed  in  the  cdata  and  cdis  files.     * 

*  superordinate  modules:  main.cmd  * 

*  subordinate  modules:  getcdata  S  getcdis  formats  * 

*  author:  Tom  Etheridge  * 
**************************************************************** 

♦set  up  environment 

SET  INTENSITY  ON 
♦set  up  the  loop 
STORE  t  TO  more 
DO  WHILE  more 

♦  set  up  screen  for  cdata  entry 
SET  FORMAT  TO  getcdata 

♦get  new  set  of  memory  variables  for  data  entry 

RESTORE  FROM  cdata 

SELECT  PRIMARY 

♦let  user  enter  data 

READ 

♦  add   data  to    the   file 

?    "       STORING    THE    DA1A ONE    MOMENT    PLEASE." 

APPEND    BLANK 

REPLACE   cnuml    WITH    mcnum,    enamel    WITH    menamel 

REPIACE   cname2    WITH   mcname2 

REPIACE   stpob    WITH    mstpob,    city    WITH    mcity,    state    WITH    mstate 

REPIACE    zip    WITH    mzip 

REPLACE   phone   WITH    mphone,    projl    WITH    mprojl,    feel    WITH    mfeel 

REPIACE    proj2    WITH    mproj2,    fee2    WITH   mfee2,    proj3    WITH    mproj3 

REPIACE    fee3    WITH    mfee3 

♦wait    for   the   user    response 

♦release   all    variables 

RELEiSI    ALL 

♦  set    screen    for   cdis   input 
SET    FORMAT   TO    getcdis 

♦get   variables   for   cdis 

RESTORE    FROM    cdis 

♦pass   the  contractor  number   to    the   cdis    file 

STORE    cnuml    TO    mcnuir2 

♦  get    the   cdis   data   file 
SELECT    SECONDARY 

♦let    the    user    input  data 

READ 

♦store  the  data  in  the  cdis  file 

APPEND  BLANK 

REPIACE  cnum2  WITH  ncnura2 

REPIACE  nad  WITH  mnad,  nee  WITH  mnee,  nog  WITH  mnog 

REPIACE  na  WITH  mna 

REPLACE  nest  WITH  mnest,  nup  WITH  mnup,  nche  WITH  mnche 

REPIACE  nge  WITH  mnge 

REPLACE  nsne  WITH  mnsne,  nee  WITH  mnce,  nhy  WITH  mnhy 

REPIACE  nsoe  WITH  mnsoe 

REPLACE  nci  WITH  mnci,  nid  WITH  mnid,  nspw  WITH  mnspw 

REPIACE  ndmn  WITH  mndmn 

REPLACE  nla  WITH  inula,  nste  WITH  mnste,  neco  WITH  mneco 

REPLACE  nme  WITH  mnnie,  nsur  WITH  mnsur,  necn  WITH  mnecn 

REPIACE  nmne  WITH  mrmne 

REPLACE  ntre  WITH  mntre,  nge  WITH  mnge 

♦are  there  more  inputs? 

IF  !  (answer)  =  "Y" 

RELEASE  ALL 

STCRE  t  TO  more 
ELSE 

RELEASE  ALL 
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STCRE  f  TO  more 
ENDIF 
*loop  tack 
ENDDC 

*set  up  the  index  on  the  names 
SELECT  PBIMARY 
INDEX  ON  enamel  TO  names 
*set  original  environment 
USE  cdata 
SELECT  SECONDARY 
USE  cdis 
SET  INTENSITY  OFF 
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Delete   Command  Module 

*******  *********************  **************************  ******  ******* 

*  delete.cmd   6/9/84   jte  * 

*  version:  1.0  * 

*  purpose:  to  delete  records  from  the  cdata  and  cdis  files        * 

*  processing  narrative:  local  variables  are  initialized,  the  user  * 

*  is  offered  a  look  at  the  records  in  the    * 

*  file  to  determine  the  contractor  number    * 

*  to  delete,  the  record  requested  by  the    * 

*  user  is  displayed  to  verify  that  it  is  to  * 

*  be  deleted,  the  record  is  then  deleted,    * 

*  first  the  cdata  file  record  then  the  cais  * 

*  file  record,  if  more  are  to  be  deleted     * 

*  then  the  loop  begins  again  else  control    * 

*  goes  back  to  the  main  menu.  * 

*  superordinate  modules:  main.cmd  * 

*  subordinate  modules:  saycdata.fmt  * 

*  author:  Tom  Etheridce  * 
******************************************************************* 

♦clear  the  screen 

ERASE 

♦initialize  the  local  variables 

STORE  t  TO  more 

STORE  "  "  TO  answer  1 

STORE  "  "  TO  answer2 

STORE  "  "  TO  answer3 

STORE  "deleted"  TO  mdeleted 

*  set  up  the  deletion  loop 
DO  WHILE  more 

7 

* 
• 

7 
7 

?  "    To  delete  records  you  need  to  know  the  assianed" 

?  "    contractor  number." 
7 

?  "    Do  you  need  to  see  a  listing  of  all  the  assigned" 

?  "    contractor  numbers  and  names?  (  Y  or  N  )  " 

♦wait  for  answerl 

WAIT  TC  answerl 

♦evaluate  the  respcnse  and  act  on  it 

IF  I {answerl)  =  "?" 

STORE  "  "  TO  answerl 

♦display  the  contractor  numbers  and  names 

ERASE 

SELECT  PRIMARY 

?  "  #     NAME" 

7 

DISPLAY  ALL  deleted,  cnuml,  enamel  OFF 
7 

?  "PRESS  ANY  KEY  TO  CONTINUE" 

WAIT 

ENDIF 

♦get  the  contractor  number 

ERASE 
7 

h 

» 

7 

7 

ACCEPT  "     What  is  the  contractor  number?"  TO  menumd 

♦find  the  record 

SELECT  PRIMARY 

SET  EXACT  ON 

LOCATE  FOR  cnuml  =  ! (menumd) 

♦check  for  eof 

IF  EOF 
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ERASE 

?  "That  contractor  number  is  not  in  the  file" 

?  "Do  you  want  to:" 
? 

?  "  1)  Try  again  or," 

ACCEPT  "  2)  Return  to  main  menu"  TO  choice 

IE  !  (choice)  =  "1" 
LOOP 
ELSE 

♦remove  the  record  and  compress  the  file 
PACK 

SELECT  SECONDARY 
PACK 

♦return  tc  main.cmd 
RETURN 
EflDIF 
ENDIE 

♦display  the  record  to  see  if  it  is  the  correct  one 
SET  FORMAT  TO  saycdata 
READ 

♦  get  the  answer2 
IE  !(answer2)  =  "N" 

STORE  "  "  TO  answer2 
LOCP 
ELSE 

♦mark  it  for  deletion 

REPLACE  deleted  WITH  mdeleted 

DELETE 

♦get   the    cdis    file 

SELECT   SECONDARY 

LOCATE   FOR    cnum2   =    ! (mcnumd) 

SET  EXACT  OFF 

♦mark  the  cdis  record  for  deletion 

DELETE 

♦find  if  we1 re  done 
7 

7 
7 

?  "  Do  you  want  to  delete  more  records?  (  Y  or  N  )" 
WAIT  TO  answer3 
♦get  answer3 
IF  !  (answer3)  =  "Y" 
♦start  over 
STORE  "  "  TO  answer3 
LOOP 
ELSE 

♦remove  the  marked  records  and  compress  files 
DSE  cdata 
PACK 

DSE  cdis 
PACK 

♦end   the    lccp 
STORE    f   TO    more 
ENEIF 
♦end   answer2    if 
ENDIF 
♦end    the    main   loop 
ENDDO 
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Query   Command   Module 

******************************************************************* 

*  guery.cmd  6/11/84  jte  * 

*  version:  1-0  * 

*  purpose:  to  permit  the  dBASE  user  to  access  the  command  mode    * 

*  processing  narrative:  the  user  is  told  the  purpose  and  * 

*  requirements  of  using  the  command  mode.    * 

*  he  is  told  how  to  return  from  the         * 

*  command  mode  to  the  menu  mode.  * 

*  superordinate  modules:  main. cmd  * 

*  subordinate  modules:  none  * 

*  author:  Tom  Etheridce  * 
******************************************************************* 

♦clear  the  screen 

ERASE 
7 

h 

7 
7 

7 
7 

?  "This  will  put  you  into  the  dBASE  11  command  mode  for  queries  " 

?  "of  the  database.  Ycu  must  know  the  command  language  to  make  " 

?  "the  queries." 
7 

♦get  the  response 

ACCEPT  "Do  you  want  tc  proceed?  (Y  or  N) "  TO  mguery 
♦analyze  the  response  and  act  on  it 
IF  !  (mguery)  =  "Y" 
ERASE 

7 

?  "To  return  to  the  menu  mode  type  DO  MAIN  in  the  command  mode." 
7 

?  "Press  any  key  tc  continue good  lucki!!" 

WAIT 
♦  exit  menu  mode  tc  command  mode 
ERASE 

QUIT  TO  'DBASE  B' 
ELSE 

♦return  to  main. cmd 
RETURN 
ENDIE 
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View    Command    Module 

*  view.cmd      6/9/84       jte  * 

*  version:  1.0  * 

*  purpose:  to  browse  thru  the  data  * 

*  processing  narrative:  user  is  given  intro  and  offered  to  see    * 

*  the  numbers  and  the  names  of  the  * 

*  contractors,  error  checking  off  inputted  * 

*  numbers  is  followed  by  presenting  the  * 

*  records  either  in  the  indexed  order  from  * 

*  the  top  of  the  file  or  beginning  at  the  * 

*  specified  number.  * 

*  superordinate  modules:  main.cmd  * 

*  subordinate  modules:  vcdata.fmt,  vcdis. f mt  * 

*  author:  Tcm  Etheridqe  * 

♦initialize  the  local  variables 

STORE  t  TO  view 

STORE  t  TO  ahead 

STORE  "  "  TO  vcommand 

*clear  screen 

ERASE 

*set  the  viewing  environment 

SELECT  PRIMARY 

USE  cdata  INDEX  names 

SELECT  SECONDARY 

USE  cdis 

*give  intro 
7 

7 

• 

7 

7  "To  view  a  specific  contractor's  data  record  you  need" 

?  "tc  knew  the  contractor  number." 

?  "If  a  specific  number  is  not  used  you  will  begin  with" 

?  "the  first  record.  The  records  are  arranged  in  alphabetical" 

7  "order  by  contractor  name." 

7 

r> 
7 
h 
? 

?    "PRESS    ANY    KEY    TO    CONTINUE" 

WAIT 

ERASE 

7 

7 
•? 

?  "The  following  options  are  available  in  browse:" 

?  "  B) ack — Takes  you  to  the  previous  record" 

?  "  Fj  orward — Takes  you  to  the  next  record" 

?  "  P)rofile — Displays  the  Discipline  Profile" 

?  "  of  the  contractor" 

?  "  N) umber — Permits  you  to  locate  a  contractor" 

?  "  by  the  contractor  number" 

?  "  Q) uit — Returns  you  to  the  main  menu" 

7 

7 

?  "Do  you  need  to  see  a  listing  of  the  contractor  numbers" 

ACCEPT  "and  names?  (  Y  or  N  )  "TO  answerl 

*set  loop 

DO  WHILE  ahead 

*get  answerl 

IF  !  (answerl)  =  "Y" 

*clear  screen  and  show  the  numbers 
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You  can  also  just  browse  thru  the  records." 


ERASE 

SELECT    PHIMARY 

7    "    #         NAME" 

7 

DISPLAY   ALL   cnuml,    enamel    OFF 

?    " PRESS    ANY    KEY    TO    CONTINQE » 

WAIT 
ENDIF 
♦  get    the   user's   desires 


ou   want   to   see 
ii  y  " 


a   specific   record?     (    Y   or    N   ) "    TO   answe 


ACCEPT  "Do 

IF  !(answer2)  = 

ACCEPT  "What  is  the  contractor  number?"  TO  menumb 
EISE 

♦if  no  use  the  first  record 
GOTO  TOP 

STCRE  cnuml  TO  menumb 
ENDIF 

♦set  uc  to  check  for  erroneous  data  entrv  and  recovery 
SELFCT  PRIMARY 
SET  EXACT  ON 
IF  !  (answer2)  =  "Y" 

LCCATS  FOR  cnuml  =  ! (menumb) 
IE  EOF 

?  "That  is  not  a  valid  number." 

ACCEPT  "Do  ycu  need  to  see  the  listed  numbers  again? 

{Y  or  N)  "  TO  bad 
IF  !  (badV  =  "Y" 

STORE  *  Y1  TO  answer  1 
LOOP 
ELSE 

?  "The  first  record  in  the  file  will  be  d isp laired.  " 
?  " — Press  any  key  to  continue — " 
WAIT 

GOTO  TOP 

STORE  cnuml  TO  menumb 
ENDIF 
ENDIF 
ENDIF 

♦end  the  loop 
STORE  f  TO  ahead 
ENDDO 

♦set  up  the  browsing  loop 
DO  WHILE  view 

STORE  enamel  TO  name 

♦set  up  the  screen 

SET  FORMAT  TO  vedata 

READ 

♦evaluate  the  choice 

DO  CASE 

♦check  option 

CASE  vcommand  =  "B" 

SKIP  -1 

STORE  cnuml  to  menumb 

* 

CASE  vcommand  =  "F" 

SKIP 

STORE  cnuml  to  menumb 

* 

CASE  vcommand  =  "P" 

SELECT  SECONDARY 

♦start  at  the  top 

GOTO  TOP 

♦find  the  correct  record 

LOCATE  FOR  cnum2  =  ! (menumb) 

♦get  the  screen  ready 

SET  FOPMAT  TO  vedis 
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♦  show  it 
REAE 
WAIT 

♦restore  the  main  file 
SELECT  PRIMARY 

CASE  vcoramand  =  "Q" 
STORE  f  TO  view 
* 

CASE  vcommand  =  "N" 

ERASE 

♦get  the  number 

ACCEPT  "What  is  the  contractor  number?"  TO  mcnumb 

♦find  it 

ICCATE  FOR  cnuml  =  !  (mcnumb) 

♦  is  it  valid 
II  EOF 

GOTO  TOP 

?  "That  number  is  not  valid.  Try  again.." 

?  " Press  any  key  to  continue " 

WAIT 
ENDIF 
♦  loop  lack 
ENECASE 

*reset  the  variable 
STORE  "  "  TO  vcommand 
ENEEO 
♦restore  the  memory 
RELEASE  ALL 

♦reset  the  main  environment 
USE  cdata 
SELECT  SECONDARY 
USE  cdis 
♦return  to  the  main  menu 
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Main  Screen  Format 

***************************************************************** 
*  main. fmt  6/5/84  jte 


2 

1 

t   o 

SAY 

2 

2, 

r      0 

SAY 

a 

3, 

r     0 

SAY 

2 

4, 

r      0 

SAY 

a 

5 

r      0 

SAY 

2 

6, 

r      0 

SAY 

a 

7( 

r      0 

SAY 

a 

8, 

r      0 

SAY 

a 

9, 

r      0 

SAY 

2 

10, 

r      0 

SAY 

2 

11, 

,  o 

SAY 

2 

12, 

r      0 

SAY 

2 

13, 

r      0 

SAY 

2 

14. 

r  o 

SAY 

2 

15, 

r      0 

SAY 

2 

16, 

,   o 

SAY 

2 

17, 

r      0 

SAY 

2 

18, 

r      0 

SAY 

2 

19, 

f    o 

SAY 

2 
2 
2 
2 

20, 
20 
20, 
21 

r      0 

r28 
,43 
r     0 

SAY 
GET 
SAY 
SAY 

MAIN  MENU 

A)  Add  a  record 

D)  Delete  a  record 

E)  Exit  (  work  completed  ) 
H)  Help 

P)  Print  a  report 

Q)  make  a  Query 

U)  Update  a  record 

V)  View  a  record 


*-  currently 


2  22,  1  SAY 


Choose  an  option:" 
ommand 
not  available         |  | " 
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Getcdata    Screen   Format 


***************************************************************** 

*   GETCDATA. FMT    6/5/84    jte 

3   1,  0  SAY  " 


a 

2, 

,  21 

SAY 

3 

4, 

r      0 

SAY 

a 

4, 

r20 

GET 

a 

4( 

,39 

SAY 

a 

4, 

,47 

GET 

a 

6 

f    o 

SAY 

a 

6< 

.18 

GET 

a 

7, 

r   16 

SAY 

0) 

7 

,18 

GET 

a 

9, 

r   o 

SAY 

a 

9, 

,20 

GET 

a 

11 

r       0 

SAY 

a 

11- 

,    7 

GET 

a 

11, 

37 

SAY 

a 

11, 

r45 

GET 

a 

11- 

54 

SAY 

2 

11 

,60 

GET 

a 

13 

10 

SAY 

a 

14, 

r      0 

SAY 

a 

14 

r  12 

GET 

a 

15 

r      0 

SAY 

a 

15, 

,     6 

GET 

a 

16, 

r     0 

SAY 

a 

16, 

r  12 

GET 

a 

17 

r     0 

SAY 

a 

17 

,      6 

GET 

a 

18 

o 

SAY 

a 

18, 

t  12 

GET 

a 

19 

r     0 

SAY 

a 

19 

.     6 

GET 

DATA  FILE" 
Number  -" 


"CONTRACTOR 

"Contractor 

mcnum 

"Phone   -" 

mphone   PICTURE    •  (999) -9 99-9999 ■ 

"Contractor   Name  -" 

mcnamel 
n_  ti 


mcname2 

"Street 

sr 

P.O.Box   -" 

mstpob 
"City   -" 

mcity 
"State   - 

ii 

instate 

"Zip  -" 

mzip 

ii   — £_      — . 

DCfi   TTTPT      HTCITnBV 

fnu J  tLl     nljiun: 

"Project 

1 

—  ii 

mproi 1 
"Fee   -" 

mf  ee  1 

"Project 

2 

—  it 

mpron2 
"Fee   -" 

mf  ee2 

"Project 

3 

—  ii 

mproi3 
"Fee    — " 

mf  ee3 
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Getcdis  Screen  Format 
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APPENDIX  B 
A-E  MANAGEMENT  INFORMATION  SYSTEM  COMPONENTS 

Below  is  a  listing  of  the  components  which  makeup  the 
A-E  Management  Information  System.  The  listing  is  broken 
into  four  categories:  databases,  files,  reports/letters 
file,  and  applications. 
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Clearances/Approvals  I  Contractor  Information 
Certif icates/Apprcvals  System 

II/III  Board  Selections 
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Signature  DD  350 

DD  1057  DD  1413 
Progress  Payment 
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Files 
Contracts 

Reports/letters 

Customer  Notification  Cost  Estimate 
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CBD  Board  Appointments 

Pre-Selection  Board  Interview  Letter 

Report  Interview  Evaluation 
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Negotiation  Board  Report  DD  350 
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letter  DD  14  13 

Contractor  Meeting  Design  Review 

Checklist  Documents 

Contractor  Release 
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